Starting Your OASIS Open Project
Whether you’re an established group with a fully scoped Project or a few people with a great idea, OASIS can provide the resources you need to achieve international recognition and widespread adoption.
There are no subject-matter limitations at OASIS. Projects decide on the technical agenda they wish to pursue. OASIS supports efforts ranging from cybersecurity, blockchain, privacy, IoT, cryptography, cloud computing, law, emergency management, static analysis, and many other areas of interest to our community. People involved in IT, telecommunications, healthcare, utilities, financial services, academia, government, and other industries all collaborate on work at OASIS.
Becoming an OASIS Open Project involves just a few, but important steps:
- Drafting a Charter
- Identifying Project Sponsors
- Selecting a License
- Submitting Your Charter
- Identifying Roles
- Selecting Collaboration Tools
- Launching Your Project
If you have a question or need help at any step in the process, please don't hesitate to contact OASIS. We're here to help you navigate the complexities of IP, governance, and community development in order to set your project up for success. Let's get started!
Drafting A Charter
The first step to starting your Open Project is to draft a charter, which describes the goals and scope of your Project and provides relevant information for attracting broad participation and feedback. Drafting the charter and getting feedback from other stakeholders helps focus your attention on what is most impactful and important to the project and helps everyone stay on the same page throughout the process.
Begin by reviewing the Open Project Charter Template. We recommend openly collaborating on the charter with others via shared editing tools like Google Docs or via an issue on GitHub. If you need help setting this up, let us know.
The template requires eight sections of content:
- Project Name - the project's unique identifier.
- Abstract - a high-level, concise (80 words or fewer) description of the project, which helps OASIS & others communicate about the project.
- Purpose and Scope - the specific problems your project addresses, described in a way that a person moderately versed in the subject area will understand. After adoption, this section can (and should!) be updated throughout your project's lifecycle.
- Business Benefits - in this section, you'll get specific about key stakeholders (organizations, vertical industries, professional communities, etc) and how they benefit from or add value the project. This section helps you and OASIS make the case for being part of the work to potential sponsors and participants.
- Relationship to Other Projects - this section helps people understand where the project fits in the current landscape. OASIS staff may also use this information to connect your project with other projects and stakeholders in the space.
- Repositories and Licenses - the list of GitHub organizations, repository names, urls, and current applicable licenses if any for the initial repositories you expect to become an OASIS Open Project. If you plan to create initialize a new GitHub organization or change licenses, you should note that here.
- Initial Contributions from Existing Work - If you plan to contribute existing specifications, repositories, or documentation to your project, provide those details and links in this section. This is particularly important for projects that may want to produce OASIS standards.
- Project Leadership - provide names, email addresses, and organizational affiliations (if any) for current maintainers and sponsors, as well as people interested in sponsoring and contributing to the project. Be sure you have everyone’s consent to list their names in the charter.
It’s a good idea to socialize your draft charter, solicit feedback, and build a core of support before the project is announced as an OASIS Open Project. Developers and organizations alike are attracted to projects that demonstrate momentum and commitment from a diverse community of partners and competitors, so spend as much time as you need to draft a clear, compelling charter. OASIS staff are happy to review and offer editorial suggestions at any point.
The final version of your charter will need to be submitted in English, but feel free to work in whatever language is comfortable for your community to get started. If needed, OASIS can help with translations when you're ready to submit your final draft.
Identifying Project Sponsors
One of the advantages of starting your Open Project at OASIS is the opportunity recruit participants from our international community. Whether you start your project with a large, robust community or a few people, OASIS staff will work with you to attract supporters before and after your project is launched.
Identifying organizations that will sponsor your project is an important step. Sponsors pay annual sponsorship dues that cover the basic support services provided by OASIS. These dues vary based on the organization's size and level of investment in the project. Each Sponsor organization has the option to appoint one representative to serve on the Project Governing Board (PGB).
Before your project can launch as an OASIS Open Project, it must meet a minimum threshold in annual sponsorship commitments. Contact OASIS for details on this. If you don’t have the minimum sponsorship for your project — or if you’d like to have more stakeholders on board before launch — OASIS staff can help find sponsors from the OASIS community and beyond.
Your charter should describe the type of organizations that will benefit from sponsoring your project and the value of participation. Be as specific as you can, as this information will help prospective members secure internal approval for getting involved.
Selecting a License
When you fill out your draft charter, you'll provide the names and descriptions for any initial repositories you expect to use for developing project assets and specify your current or preferred license for each repository. Each OASIS Open Project Repository is governed by the open source license selected by the Project Governing Board.
Licenses offer different patent guarantees, reuse rights, and requirements that implementers will need to comply with. Not sure which license to choose? OASIS has decades of experience in IPR policy and can offer assistance to help you determine what’s right for your project. You can see the current list of supported licenses here.
Contributor License Agreements (CLAs) bind project contributors to the license, ensuring that the contribution is available and implementable under clear legal terms. OASIS Open Project CLAs feature a special Specification Non-Assertion Covenant that assures work produced can be advanced to Project Specification or OASIS Standard status without patent issues or ambiguities.
Participants do not need to sign CLAs in order to review and comment on technical work, file bug reports, and make other non-substantive change requests to Open Project work products. People who wish to make substantive contributions to OASIS Open Projects are required to complete and submit an Individual Contributor License Agreement (I-CLA). If a person’s contributions represent intellectual property owned by a company, organization, or other corporate entity (i.e., contributions made as a designated employee or representative of the entity), then the corporate entity should also complete and submit an Entity Contributor License Agreement (E-CLA). E-CLAs must be signed by all organizations with representatives on Project Governing Boards.
Once your license has been selected, OASIS staff will set up the CLA collection and auditing tool for your project.
Submitting Your Charter
Contact the OASIS Project Administrator as soon as you are ready to submit the final draft of your charter. We will review your charter for completeness and ensure it meets all requirements. If something’s missing, we’ll help you address it.
Submitting your final charter kicks off our internal pre-launch checklist process, wherein we confirm all the tools and required paperwork are in place to "go live" with your Open Project!
There are many ways to participate in an Open Project, formally and informally. Anyone can view the Project’s activity, assets, and repository forks, and download copies of repositories. Participants (anyone with a GitHub account) can submit comments, report bugs, open issues, and request new features. Contributors are people who have signed the project's CLA and thus can submit contributions by creating pull requests.
Maintainers maintain the codebase, review and approve pull requests, build binary packages for distribution, and generally act as the editors and managers of the project's repositories. As such, commitment and expertise are key criteria for selecting Maintainers. Maintainers see to it that the technical consensus of the PGB and the community guide the project work. An Open Project must have at least one Maintainer; ideally there should be a maintainer team overseeing all of the project's repositories.
The Project Governing Board (PGB) develops and manages the overall product strategy of the Project, votes on major releases, and decides if/when to submit work for standards approval. They are responsible for ensuring that there is a designated Maintainer for project repos. They are also responsible for making sure important updates and messages about the project are sent to the community in a timely fashion, via mailing lists and social channels. A PGB may choose to form additional committees and/or other groups related to project efforts, such as marketing, events, and so forth, to delegate these tasks.
The PGB will select one or two of its members to serve as Chairperson(s). The role of the Chair is to manage the PGB’s logistics, agenda, and decision-making. The Chair(s) help the PGB reach consensus on topics, coordinate and lead meetings of the PGB or the broader community and, when needed, work with OASIS staff on related events, assist the maintainer(s) when necessary, and act as the project's main point of contact with OASIS staff. PGB activities are suspended while the Chair role is vacant.
The Technical Steering Committee (TSC) is chartered by the PGB to direct the day-to-day technical activities of the project. The TSC may be comprised of Maintainers, Contributors, and Project Sponsors as best suits the project - the responsibilities, appointment criteria, and size of the TSC is determined by the PGB in concert with the needs and preferences of its community.
As you prepare to launch your Open Project, it is important to identify the people who will be filling these important roles and help them understand and accept their responsibilities. Projects may chose to adjust these roles or add new ones, but the structure outlined in this section describes the minimum governance model required of all Open Projects.
Open Projects must create and publish documentation outlining the requirements for joining and decision-making in the project's TSC. Increasingly, it is considered a best practice to include a GOVERNANCE.md document on your project repositories that describes the leadership roles and decision-making process your project uses. This helps newcomers understand how decisions are made, who they can talk to for additional information, and how they can possibly get even more involved in project maintainence. You can use our GOVERNANCE.md template to get started, or publish this information on your project README, as long as it is clearly marked and accessible to the public.
Selecting Collaboration Tools
Chances are, your project already relies on a number of the same software collaboration tools we recommend for OASIS Open Projects. OASIS requires Open Projects to have publicly accessible tools for collaboration and development (see our visibility policy for more information).
If your project doesn't yet have tools for things like integrated issue management, project boards, version control, release management, or Wiki pages, OASIS can help you set them up. Additionally, OASIS will support publicly archived email discussion lists and coordination with maintainers of any custom web sites or community portal web sites associated with an Open Project.
OASIS Open Projects are expected to use git and GitHub for most collaborative development tasks. Projects are also strongly encouraged to have a website and use social media channels to socialize their work. OASIS can help set these tools up, or even maintain them, if needed.
Your project's PGB may elect to adopt additional collaboration or workflow tools after the project launches. Any tools selected for official use by the project must be cleared with OASIS - because Open Projects are expected to conduct business in public view, we want to ensure that access and archivability are prioritized.
As part of the internal pre-launch checklist process, we will review your project's existing toolset and determine if there are any gaps. Subject to resourcing and policy constraints, OASIS may provide additional online resources for Open Projects that may be needed in the future.
Launching Your Project
OASIS will officially launch your project as soon as possible after your final charter has been submitted and reviewed, and the pre-flight checklist has been complete.
OASIS will announce the project via press release, and issue an invitation to participate via OASIS websites, mailing lists, and social media channels. We will also work with Project Sponsors and community stakeholders to help them amplify the launch message to ensure maximum reach.
With your project launched, it's time to get busy collaborating! Check out these additional guides for more help, or contact OASIS to take your next step as an Open Project.