NOTE

This wiki document was created without a public discussion which was wrong on our part. Please refer to #8 for discussions on this topic.

---

Open source projects come with a unique set of challenges, brought on by the lack of central control over the people participating in the project. Each open source model comes with its own set of risks, but all open source projects share the following risks:

Code quality and application security

These can be mitigated with proper identification of an appropriate organizational structure and review process. For example, code may undergo peer review for quality assessment. Known application vulnerabilities would be mapped against code and resolution prioritized. Specifics will be part of recommendation for deliverable #4.

Contribution of features outside of project scope

As above, these can be mitigated with proper identification of a core team who implements a pull request process with thorough review. Contributors will be encouraged to create an issue so that a discussion of the feature, its value, risks, and trade-offs can proceed before time is spent on development.

The core team must be clear about the scope of the project and the overall roadmap of priorities. Specifics will be part of recommendation for deliverable #4.

Contribution of code that does not conform to the architecture of the project

This risk is also mitigated by the review and issue creation process. The core team will need to be explicit about its architectural decisions and firm in enforcing them as necessary. Specifics will be part of recommendation for deliverable #4.

Intellectual Property and Contractual Rights

To protect the legal rights of OS users. The SDLC should include controls (e.g., code scanning) for the risk of a developer taking code from somewhere else (Oracle, MS) and incorporating such code into the OS.

Lack of engagement from the community

If the community is not managed and engaged properly, enthusiasm will fall off (or never build), and code contributions will be few and far between. Recommendations on managing, and then growing, the community will be detailed in Deliverables #5 and #6.

Licensing selection and compliance.

Details to follow in Deliverable #1.

Component licenses : if appropriate include in the SDLC a review of components. Adopt appropriate controls (e.g., identifying, generating, and maintaining license notices report to include with shipped software).

Reuse : certain restrictions may hamper our ability to share with other cities and application providers Care must be taken in selection of a license that permits the use and growth of the operating system.

Indemnification : As with any indemnification provision, the language the OS uses must be considered in the context of the project's objectives. If a user were to get sued for intellectual-property infringement over code they received from the OS, the language/terms would be triggered.