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, AI, digital trade and commerce, and many other areas.
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!
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 - Full name and short name or acronym. The will be the project's unique identifier. Do not use the word 'OASIS' as part of the full name or '-oasis' as part of the short name. The words "OASIS" or "OASIS Open" are an indication of source, and should not be integrated into the project's name directly. We find it is also good to find a name that is short, easily pronounced, and memorable.
- Abstract - A high-level, concise (80 words or fewer) description of the project's purpose which helps OASIS & others communicate about the project.
- Statement of Purpose - 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.
- Normative Scope - Here you provide details on the work you intend to do to achieve your stated purpose. Clarify what work will be the focus of the project as well as any work the project will explicitly not undertake. You may also want to list specific deliverables and/or your proposed timeline in this section.
- 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 - List initial repositor(ies) you would like to set up with the preferred licenses for each, chosen from the list of approved licenses.
- 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.
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.
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.
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, it must have enough annual sponsorship commitments to cover the costs of the services and support you'll need to accomplish your goals. Contact OASIS for details on this. Once you have enough initial sponsors on board, OASIS staff will take on responsibility for outreach to the broader community.
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.
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 and Technical Steering Committees.
Once your license has been selected, OASIS staff will set up the CLA collection and auditing tool for your project.
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. In general, a suitable maintainer should be an expert in one or more fields related to the project and should be able to contribute in ways that substantially improve the quality of the project and the experience of people who use it.
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.
Ideally, your company’s PGB representative is a person that has decision making ability on related issues at your company and is able to commit to monthly meetings.
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 composed 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.
We recommend that one or more of the TSC members is familiar with Open Source processes and GitHub.
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.
OASIS requires Open Projects to use publicly accessible tools for collaboration and development (see our visibility policy for more information). These tools include integrated issue management, email lists, project boards, version control, release management, Wiki pages, chat, video conferencing, website, etc. If your community is already using tools we support, OASIS staff will help transition them to your new project. Otherwise, OASIS staff will set up the tools covering in our Core Services.
Most OASIS Open Projects use git and GitHub for the majority of their 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 and maintain them, with content provided by designated members of your community.
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.
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.
After the first meeting of the PGB, OASIS will issue an official press release announcing your project and its initial sponsors. Sponsors will have the option to be quoted in this press release, and the announcement will be promoted via the main OASIS website, 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.