In January, we launched the Open Metaverse Foundation, home to an open, vendor-neutral community dedicated to creating open standards and software to support the open, global, scalable Metaverse. It’s been amazing to see the active, thoughtful discourse and discussions since then through weekly meetings and a thriving Discord channel. Building an interoperable infrastructure for the Metaverse is a monumental task—and an exciting journey. Only through open collaboration will we make true progress, and ultimately, realize its promise.
One of our primary goals of the Open Metaverse Foundation is to identify and iterate on the components that will ultimately enable us to bring the vision of an open and interoperable Metaverse to life.
So how does our community chart a strong course, establishing clear priorities and defining tangible steps? Where do we begin?
To do this, we need to work in stages where we can do much of the work in parallel, yet in an orderly fashion.
1. Document and identify a very high-level, and not very technical description of what we are trying to achieve. This is to give us the visionary rails to operate within, provide the context, and form a mental picture of our first destination.
2. Take the document from the first step and distribute the narrative to each of the Foundational Interest Groups. Each FIG will be tasked with interpreting each sentence and providing a list of features that can fulfill the statement in that sentence. As each FIG will have a different interpretation given the context of that group’s focused interest, we will have a robust list of features that will be combined and deduplicated.
3. Each FIG to categorize each feature as a core feature (absence will prevent basic presentation or primitive interaction directly or by dependency) or extension feature along with a rank up from 1 to any number. The rank cannot be duplicated, and the highest priority is 1.
4. All lists will be combined with the highest values and reranked. Features will then be scoped down into a minimal subset to create an achievable goal for a one-year cycle.
5. Each FIG will insert its features into its feature state graph. They will research and identify potential open-source projects that may fulfill some of the features with minimal revision. As they find the projects, they will put them into a list document in GitHub organized by feature.
6. FIGs will then rerank the features by complexity to achieve the feature needs. When the projects have been identified, they are submitted to the TOC with a form providing information about the feature, proposed project, anticipated timeline, complexity, and planned work.
7. Once identified, the FIG proposing the project will reach out to the owning community to determine if they wish to bring the project into the OMF to receive support (marketing, awareness, engineers and community), or if they wish to be supported by the OMF creating a project that will fork and work on updating the code to achieve the features required and provide updates to the upstream.
8. The TOC will make a decision based on the information provided to ensure no duplication or intellectual property constraints exist to prevent issues with working on that project.
9. Once the project is formed with a technical steering committee, code repository and SIGs, if appropriate, it enters the sandbox stage.
Sandbox Projects:
As each project begins, it will start in a “sandbox” state. This is where it has little community, support, or code maturity in relation to the feature it is focused on achieving.
The sponsoring FIGs will review the progress of each sponsored sandbox project each month, and upon request. As each project matures, the sponsoring FIG(s) may submit an “incubation” promotion request to the TOC. The project must show basic functionality, with a testing component, complete with documentation and a community commensurate with the project’s size.
Sandbox projects will receive support to assist with the operational processes, templates, management, initial engineering and/or engineers, public project awareness, and community outreach to help grow their projects with the goal of becoming self-sustaining. They will receive guidance and support from the sponsoring FIG(s).
The TOC will evaluate all requests and respond with comments or promote each project to an “incubating” project.
Incubating Projects:
As a project enters the incubation stage, it is evaluated to determine if the work will be positioned as a standard. If it has been determined by the FIG that it be recommended for standardization, a request will be submitted to the TOC. Once accepted by the TOC, a standards working group will be formed for the project.
All contributing individuals to the project that wish to work on the standards specifications or be a part of the standards working group will be required to have signed an intellectual property agreement that ensures that the rights to all documentation and contributions for the standardization specification by the contributor are being donated without patent, copyright, or trademark restrictions to ensure standards are royalty free for worldwide distribution upon completion. Any individual participating in the standards working group may also continue to contribute to the project, but all standardization work must be performed within the working group. The signing of the IP agreement is not required for continued code development, which will continue in the open with the community.
Incubating projects may receive further community visibility, blogs, speaking sessions, and fiscal support from the foundation to scale the project’s capabilities, community, and corporate adoption.
Graduated Projects:
As the projects continue to mature and become completely self-sustaining, they may be evaluated from time to time by the TOC and/or FIGs. When a project has achieved a 1.0 (better term here) public release with complete documentation, a stable testing suite for interoperability testing, a portable code library, and, if developed, a standards-based specification ready to publish, the project may be promoted to the “Graduated” stage.
When a project has reached a graduated stage, the standards-based specification will be finalized and approved by the TOC for submission to a standards development organization.
Graduated projects may receive greater community visibility, event tracks, sponsored sessions, blogs, and fiscal support from the foundation to sustain and support the project throughout its lifecycle.
—
Tracking the lifecycle of the projects:
Each FIG will maintain a feature state board in their GitHub repo. The boards will contain the features related to that FIG along with the information of the feature.
Example board for FIG-Digital Assets:
https://www.o3de.org/docs/release-notes/22-10-0/feature-state/
There are 3 types of boards:
- Project Board: Depending on complexity, used by projects to show maturity
- Foundational Interest Group Board: Scoped to features focused upon by FIG areas.
- Metaverse Feature Board: This contains all FIG boards to show a ‘state of the union’ of all work.
The MVP feature board is always focused on achieving that year’s goals to ensure the specific areas are given highest priority.
As projects are brought in and matured they are updated each month by the advising FIG on the feature board from the project Technical Steering Committee (TSC) and Special Interest Groups (SIG).
FIGs maintain an active project board in Github under their respective FIG areas.
Projects are assisted by the foundation and its groups to provide structure and project management best practices to ensure a steady flow of information and production are maintained.
Every two weeks, the FIG chairs and the TOC will meet to help drive resources into the areas that need it the most.
—
Foundational Interest Groups have weekly meetings to refine the efforts of defining the features, refining their scope, identifying potential open source projects, and proposing projects for approval to the TOC for standards and adoption review.
FIGs meetings will be called and maintained by the chair and co-chair, which shall be elected by the community each year according to the processes contained in the election guide.
—
As our community grows, we want to be sure that we are working with other communities and projects. Some of them will have people that are designated as Liaisons. These individuals are an excellent resource to convey information between our communities and will be a critical resource for both. We want to strive to share as much information to ensure our mutual growth and success.
We will also be creating a Diversity & Inclusion committee and a Marketing & Outreach committee. Each of these committees will be responsible for each of the respective areas with their own charters of operation. They are a critical part of our foundation to ensure we are represented, improve our outreach, and stay balanced as a foundation. They will attend and advise at the Technical Oversight Committee and Governing Board meetings. These committees may be joined by anyone in the community and shall have an election each year for the chair and co-chair.
Your engagement and participation are essential to the success of our mission and the broader community. If you have comments, questions or suggestions for refinements, we encourage you to share them so that we can grow stronger, together.
