OGC Collaborative Solutions and Innovation: Policies and Procedures

For sponsors, the OGC COSI provides a unique opportunity to develop solutions for geospatial IT challenges. OGC COSI provides the ability to determine market interest and validates the willingness of researchers and industry to address specific interoperability issues. The rapid prototype development yields workable interface specifications in months, potentially saving years of time in the standards development processes. Participants test, validate, and demonstrate interface integrity by implementing candidate specifications in their products (reducing the risk that a proposed standard will not perform as intended). The accelerated process encourages rapid time to market for Standards-based solutions with OGC member vendors typically becoming early adopters of draft standards.

Return on Investment for sponsors is substantial: typically for every Euro, Dollar, or other currency equivalent in sponsors funding, initiatives have yielded more than two times as much in terms of level of effort. This return is possible due to the alignment of OGC initiative activities with on-going activities of OGC members. Participants in many COSI initiatives even contribute more in in-kind contributions (e.g., labor, software, infrastructure) than what is funded by sponsors. The results are sustainable as vendors want early influence in specification development as well as skill building, visibility, and opportunity for early market deployment of standards.

For Participants, the benefits focus on the opportunity to cooperatively develop interoperability solutions that might become open standards. Participants gain early insight into user requirements for interoperability and early experience with and influence in developing standards in the context of user business cases. Vendor Participants are able to bring new products and services using OGC Standards into the marketplace earlier. Participation reduces development costs, risks, and lead-time for developing interfaces through a community-wide cost sharing model. The overall result is a broader market reach via products that implement OGC standards.

Another important outcome of OGC COSI initiatives is reduced risk associated with emerging interoperability solutions. The risk reduction is based on creating reference implementations that use draft standards and by validating these technologies with real world business cases in a collaborative environment of sponsors and Participants.

OGC COSI initiatives promote rapid prototyping, testing, and validation of technologies (e.g., standards or architectures). Within an initiative, OGC Members test and validate draft specifications to address geospatial interoperability requirements in real world scenarios, business cases, and applied research topics. This approach not only encourages rapid technology development, but also determines the technology maturity of potential solutions and increases the technology adoption in the marketplace.

The Technology Readiness Levels (TRL) scale serves as a planning tool for innovation management. The TRL scale was developed during the 1970-80’s by NASA to enable assessment of the maturity of a particular technology and the consistent comparison of maturity between different types of technologies. Since then, the TRL scale has spread to other communities, though with significant adaptation. It is now used by various organizations, from governmental departments to large companies. Indeed, it is the key element of many Technology Readiness Assessment (TRA) methods. OGC has adopted a TRL scale as developed by the European Association of Research and Technology Organisations (EARTO).

Development of high-tech technological systems typically depends on the successful synchronized development of the individual technologies needed. Assessment of the readiness of the individual technologies will allow risk reduction in budget and planning. OGC has adopted the TRL scale to describe the readiness of geospatial IT solutions in the context of standardization and interoperability. The OGC adoption does not focus on a single technology, but takes multi-technological aspects into account where necessary and thus allows the TRL scale to remain one-dimensional. This approach allows estimating technology maturity of individual technology elements that make up the technological building blocks of user scenarios and business processes. The use of TRLs enables consistent, uniform discussions of technical maturity across different types of technology.

Based on the OGC TRL scale, OGC COSI defines various types of initiatives as illustrated in Figure 4. These initiatives follow the TRL scale to allow stepwise development of initial ideas towards robust and mature products, processes, services, or technologies. The various initiative types further differentiate from each other based on the variety of work items within an initiative, duration, and sponsoring concepts.

Initiatives on the lower levels, such as TRL 2-3, focus on research and experimentation. Design Experiments, Sprints, and most of the work performed in Testbeds are located here. The result of the work are reports that eventually serve as content for draft specifications.

Initiatives that take place in the intermediate TRL levels TRL4-7 use adopted standards as a baseline. The main purpose of Pilots, Interoperability Experiments, or Plugfests is to enhance existing technology, explore its readiness for market, test deployments in specific domains, or the execution of cross-product interoperability assessments. Impressive demonstrations and Change Requests towards existing standards are typical outcomes of this types of initiatives.

OGC COSI initiatives usually stop at TRL 8 levels. Here, Operational Exercises allow the exploration of technologies, products, services, or processes to new markets or domains.

The OGC COSI initiative type Engineering Services is the technically more agnostic to Technology Readiness Levels, though specific implementations of this type of initiative usually focus on specific levels as well. The various initiative types feature a common set of initiative roles and often share similar initiative phases, and types of initiative deliverables, which are described in the following sections. Differences for the various initiative types are described in the corresponding sections.

COSI initiatives usually start with either a request or idea from a sponsoring organization or with a request from an OGC board, committee, or Working Group. Alternatively, an OGC member invites OGC to join a consortium that plans to respond to an open tender, or OGC staff decides to initiate an activity on its own. In any case, the OGC COSI Review Board convenes to review and to approve/reject the request/idea.

Once an idea or request is approved, the OGC COSI TEAM starts the development of the initiative concept. The concept describes the requirements and outlines a draft technology, system architecture, conceptual model, interface structure, or other technology. As part of the concept development, the COSI TEAM discusses the initiative type with the sponsors. The final decision on the initiative type is with the COSI TEAM. The matured concept then serves as input for the next phase.

A CDS may include a Request for Information to obtain additional information from OGC members or other organizations. A CDS results in an Engineering Report that contains information resulting from the engagement with OGC membership and the broader community of experts. The CDS Engineering Report is delivered to sponsors and released to the public, whereas simple initiative concepts are usually shared among sponsoring organizations only.

If the concept identifies a need or opportunity for additional sponsors, then a Call for Sponsors follows the concept development phase.

Self-Contained Concept Development (Study)

Depending on the expected effort to develop the concept, this phase can be executed as a self-contained Concept Development Study (CDS). A CDS is a sponsored activity where the COSI TEAM develops a comprehensive overview of a given subject. CDS are executed under the umbrella of Engineering Services.

The Call for Sponsors (CFS) is an optional phase to seek one or more funding organizations to support an initiative. A Call for Sponsors is a formal request that might occur if:

Types of Sponsorship

The following types of sponsors are sought:

Call for Sponsors Document Content

A CFS document will include at least the following information:

Sponsor expectations

Because a CFS occurs before contracting, the responding parties are responding in good faith and final negotiation of sponsors details will occur once the CFS closes. Similarly, the CFS deadline may be extended as there are no contractual obligations under a CFS.

The COSI TEAM receives CFS responses and contacts the potential sponsors to understand their interest, offered sponsors, and any requirements from sponsors of the OGC or initiative Participants.

Once the concept has been defined and depending on the initiative type, the development of a Request for Information or Call for Participation starts. Both documents are eventually released to the public with the goal to seek interest by the geospatial community in an COSI initiative.

The Request for Information (RFI) is a formal process to gather information from OGC members or broader communities of experts about particular interoperability issues or technologies. The RFI is formulated upon the Concept Development, sponsor requirements, and the existing OGC Standards baseline.

The intention of an RFI is that organizations (i.e., government, industry, universities, and other organizations that work within the geospatial market) will review their technology capabilities, best practices, research and development, and design ideas and respond to the RFI with recommended technological approaches to the issues described in the RFI.

The COSI TEAM will review the RFI responses and develop an Engineering Report that documents the responses to the RFI, the benefits of given recommendations, the probable costs (if possible), an appraisal of where the recommendation seems to fit within the overall context of industry practice, and a draft technical architecture. The RFI report will be handed over to the Sponsors for further consideration. On receipt of the report, the Sponsors are then in a position to make a decision on how best to proceed: whether to fund an initiative or to reconsider the requirements submitted and go through the process again.

The Call for Participation (CfP) defines the technical background, requirements, an initial architecture, and work to be performed within an initiative. The Call for Participation is based on the developed concept or a previously conducted Concept Development Study (Figure 6, Step 1). It also provides stakeholder role descriptions, proposal submission instructions and evaluation criteria, a master schedule, and other project management details.

In the process of CfP development, the COSI TEAM works closely with the sponsors on the scope of the initiative (Figure 6, Step 2). The COSI TEAM formalizes the requirements, designs an initial architecture and corresponding deliverables, and draws up a budget for the activities required to address the requirements. It is the goal for each initiative to have at least two implementations of each software component to test and enhance interoperability most efficiently. The CfP and budget development is an iterative process to allow Sponsors to define the optimal set of requirements and corresponding work items (Figure 6, Step 3).

The Call for Participation provides all necessary information to the general public that is necessary to respond to the call. The CfP allows applicants to explain the technical contribution they intend to make, how their contribution maps to the deliverables and activities, the cost-sharing funds they are requesting to offset their engineering costs, and the in-kind contributions they will make.

The time to respond to the CfP is usually 30 calendar days. All Calls for Participation are released publicly (Figure 6, Step 4).

The responses are sent to the OGC and reviewed by the COSI TEAM (Figure 6, Step 5). Technical proposals are made available to all initiative Sponsors.

The Team Formation phase starts soon after the CFP has been closed and all proposals have been received (Figure 7, Step 1). This phase identifies and contracts the best organizations to participate in an initiative. After the CFP response deadline, the sponsors and the COSI TEAM perform a review process for the selection of Participants. The criteria for proposal evaluation are defined in the Call for Participation.

The COSI TEAM presents recommended Participants to the sponsors in one or two Technical Exchange Meetings (TEMs). Additional TEMs may be required to solve issues such as no responses received to address a deliverable, submissions which were not clear, or proposals exceeding the initiative budget (Figure 7, Step 7-9). At the final TEM, the COSI TEAM and Sponsors will reach an agreement about the Team formation and the deliverables assignments to the Team members. In case of conflict, the final decision about Team formation is with the COSI TEAM. The COSI TEAM will determine the specific distribution of funding to Team members.

In case of lack of proposals for specific work items, the COSI TEAM works closely with the sponsors to find solutions. Both sponsors and COSI TEAM can suggest OGC members to solicit for interest in taking on the work item(s). During this process, sponsors may even suggest non-member organizations as possible candidates. Principal and Strategic OGC members may make use of their membership assignment options to facilitate the non-member admittance process.

When decisions with regard to Participants’ funding have been made, COSI TEAM will notify the proposing organizations of the outcome of the TEMs. Once the selected Participants have been notified, the OGC will begin negotiations with the selected Participants. These negotiations will discuss funding, tasks to be performed, in-kind contributions that will be provided by the Participant, and the nature of the statement of work. These negotiations will form the basis of an agreed to Statement of Work (SOW) and a contract between OGC and the Participant in question (Figure 7, Step 5). While this process is expected to be iterative as terms of the contract are finalized, the contract is the basis for the relationship between OGC and the Participant.

Participants are expected to be OGC members. If a selected Participant is not an OGC member, that Participant should begin the membership registration process. Membership will be required before the final Participant contract is signed. Once the OGC COSI TEAM has decided that negotiations are at a reasonable state of completion, the COSI TEAM will complete work on the overall architecture, initiative schedule, initiative concept of operations, work packages, and further materials that will be provided to the sponsors and Participants at the Kickoff meeting.

Many COSI initiatives require Participants to provide some level of in-kind contribution (i.e., activities or deliverables offered with no expectation of financial compensation). Where in-kind contributions are required, general guidance is that a proposal should include at least one dollar of in-kind contribution for every dollar of cost-sharing compensation requested, unless otherwise specified in the CFP. Participation may be fully in-kind.

A Kickoff is a meeting where the initiative scope and schedule is discussed with sponsors and all Participants. The Kickoff meeting offers an opportunity for the COSI TEAM and sponsors to highlight the purpose of the initiative and allows Participants to ask questions to clarify their responsibility. The meeting is led by the Initiative Architect. The meeting can occur physically (face-to-face) or virtually (web- or teleconference), depending on what the COSI TEAM and sponsors deem appropriate. Large initiatives almost always require physical meetings. Participants will be required to attend the Kickoff to be introduced to other Participants, the COSI TEAM, and sponsors.

The Agile Development phase is the actual execution part of an initiative with all sponsors, Participants, and the COSI TEAM working on the requirements and work items as defined in the Call for Participation. The Agile Development phase follows agile principles where Participants are encouraged to show results as soon as possible. This approach allows timely feedback to the Participants from the COSI TEAM, sponsors, and other Participants. The Agile Development phase starts with the Kickoff meeting. Afterwards, Participants will meet regularly (usually once per week) via web meetings and teleconferences to discuss solutions and report progress.

Depending on the initiative type, the agile development includes several stages, starting with a review and status quo discussion of all work items listed in the Call for Participation. Moderated by the COSI TEAM, Sponsors and Participants can mutually agree to modify work items at this stage (Figure 8, Step 11).

After the initial refinement, all work items are then explored in prototypical implementations. In an agile process, prototypes and design decisions iterate until a satisfying level of maturity has been reached. Design decisions, reasons for technology selections, and other important items are captured in Draft Engineering Reports (Figure 8, Step 12).

Once design and implementation have reached the necessary level of maturity, all components are tested in Technology Integration Experiments (TIEs). The COSI TEAM always tries to have at least two implementations of each component to test and enhance interoperability. TIEs bring the components developed by the various Participants together to test interoperability (Figure 8, Step 13).

If compliance testing is part of an initiative, then components developed are tested through the OGC validation tools. Additional compliance tests may be developed as part of the initiative.

OGC COSI Initiatives demonstrate all results at the end of an initiative. For that reason, COSI TEAM, Sponsors, and Participants develop a Demonstration Concept that may include elements such as live demonstrations, video material that highlights the main achievements of an initiative, blog articles and other form of social media, and other outreach material that helps to communicate the results of the initiative (Figure 8, Step 14).

The formal products of an OGC COSI Initiative are Engineering Reports and Change Requests to existing OGC Standards. Both are developed in a joint effort of all Participants in an COSI initiative, led by a dedicated document editor as main author. Engineering Reports undergo the formal OGC public release process, which includes review periods and votes by OGC committees. The detailed process is defined in the OGC Policies and Procedures. All Engineering Reports and formal Change Requests are handed over to the OGC Standards Program for further consideration (Figure 8, Step 15-16).

The length of the agile development phase depends on the type of initiative. The phase spans from hours at a Sprint activity to several months in the case of Testbeds. Some initiative types foresee Interim Workshops where Participants, sponsors, OGC members, and invited experts meet to discuss a specific technology topic that is key to an COSI initiative.

To support this phase, OGC provides state of the art web collaboration tools, including content management systems, wikis, FTP sites, unlimited web conferences, GitHub/Gitlab repositories, cloud hosting, and mailing lists.

A demonstration event provides the venue to present the accomplishments of the Initiative. The demonstration event will include a general overview provided by the Initiative Architect and Participants should have the opportunity to showcase the results of their work. The demonstration event also provides the opportunity for sponsors and Participants to interact, discuss any final issues, and plan future efforts. The demonstrations are generally held physically, but in some circumstances can be virtual.

Outreach activities following an initiative will include a persistent landing page on the OGC website detailing the initiative work and results, public Engineering Reports, and optionally, blogs, video material, press releases, and articles/publications. The COSI TEAM coordinates and mentors all outreach and will facilitate permissions for publication of initiative results by sponsors and Participants. Canned videos will be posted in the OGC YouTube channel.

Depending on the explicit requirements stated in the Call for Participation, some prototypes may be available in live servers for a specified period of time beyond the end of an Initiative execution for continued use. The time and conditions are subject to the terms of the Participants agreement.

Engineering Reports (ERs) are prepared in accordance with an OGC published template. ERs are the formal mechanism used to deliver results of OGC Collaborative Solutions and Innovation to Sponsors and to the OGC Standards Program for consideration by Standards Working Groups and Domain Working Groups before ultimate approval by the OGC Technical Committee (TC).

ERs typically contain some or all of the following information. Note that the content of an ER is dependent on the nature of the initiative.

Once initiative Participants and sponsors agree on an ER’s contents and that the ER should be approved by the TC for public release, the ER is posted to Pending Documents on the OGC Portal. ERs do not represent the official position of the OGC, but are endorsed by the OGC Technical Committee.

Engineering Reports may describe best practices or provide user guides for specific technologies.

Change Requests (CRs) are the formal process by which changes are suggested for OGC standards and evaluated by the Standards Working Group (SWG) controlling any standard. Where existing OGC standards are being used as part of an COSI initiative, the initiative Participants are encouraged to create CRs whenever deficiencies or improvements are identified for OGC standards. CRs are posted by the COSI Participants to the public using the OGC Change Request online tool.

All COSI initiatives are required to provide feedback to relevant OGC Working Groups. Usually, this takes the form of presentations at Technical Committee meetings.

Implementations take the form of Services, Clients, Datasets, and Tools provided by methods suitable to the implementation type and stated requirements. For example, services and components (e.g., a WPS instance) are delivered by deployment of the service or component for use in the Initiative via an accessible URL. A Client software application or component may be used during the Initiative to exercise services and components to test and demonstrate interoperability; however, the application or component is most often not licensed for usage after the initiative ends. Implementations of services, clients, and data instances may be deployed in multiple threads of a complex initiative for integration and interoperability testing in support of the agreed-up thread scenario(s) and technical architecture. The services, clients, and tools may be invoked for cross-thread scenarios in demonstration events.

A set of code that implements an Abstract Test Suite of a specification. The test is written to be executed in the OGC Validation Engine.

Demonstrations are events or online resources that present the major accomplishments of the initiative. They are one of the mayor outcomes of an initiative.

OGC Design Experiments qualify at the lower end of the TRL spectrum. Design Experiments seize the idea to develop new specifications, e.g. a new API type, data model, or data container. Design Experiments are very focused initiatives that run the whole gamut of the initiative phases. Design experiments usually provide cost-sharing funds and are managed by the COSI TEAM. Design Experiments are required to deliver their results as Engineering Reports or Change Requests. Design Experiments commonly have an agile development phase of 2-6 months.

OGC Sprints experiment with emerging ideas in the context of geospatial standards, help improve interoperability of existing standards by experimenting with new extensions or profiles, are used as proof of concept for other OGC Collaborative Solutions and Innovation initiatives, or support OGC Standards Program activities.

OGC Sprints are very short and focused initiatives that are often executed within few days to weeks. Sprints put most of their emphasis on the agile development phase that is usually executed during a physical meeting. Located at TRL 3-4, Sprints usually build on existing technology and develop extensions, profiles, or complementing new technology.

At OGC Sprints, technology and domain experts, programmers, and program managers come together to develop new and enhance existing specifications in an agile way. At OGC Sprints, development is pushed forward and at the same time coordinated to ensure minimum redundancy and consistent use of common elements across the growing set of OGC standards.

OGC Sprints are not necessarily managed by the COSI TEAM, but optionally by OGC working groups or OGC member organizations with support from the COSI TEAM. Sprints sometimes include sponsors and provide cost-sharing funds to cover travel expenses. Sprints are often open to non-member organizations and execute shortened initiative phases with less stringent concept developments, calls, team formation, demonstration, and outreach phases. Sprints often provide direct, informal input into OGC working groups and are not required to deliver Engineering Reports as formal results.

OGC Sprints cover activities that are sometimes referred to as "Hackathons". As such, Sprints bring together computer programmers and others involved in software development, e.g. graphic designers, interface designers, project managers, end-users, and subject-matter-experts. Programming-oriented Sprints emphasize rapid programming to support the development of new applications, new software capabilities, and open standards.

Intellectual Property Rights Policy for OGC Sprints

Sprints fall under three different Intellectual property rights (CIPR) domains, depending on where the source code, generated by a Participant during the Sprint, resides after the event.

Participant source code is not shared or transferred to the OGC or another party:

OGC Challenges

Special cases of Sprints are OGC Challenges. Challenges are events where Participants advance the development of new applications, new software capabilities, and open standards according to sponsor-defined scenarios or use cases. In some cases, the prizes might be cash.

In contrast to normal Sprints, the physical meeting of Challenges may take place several weeks after the kickoff meeting. Participants are expected to attend a final judging event where the proposed solutions are demonstrated in person. Participants may be required to turn in information about their solution to be evaluated early on, approximately two weeks, before the final demonstration face to face judging event.

Sponsors, OGC Members, outside experts, and OGC staff (in rare occasions) are potential judges for the Challenges. In all cases, attempts will be made to secure a minimum of at least three judges.

Some challenges may include finalists, winners, and prizes. Other challenges might not have winners. Is up to the team (Sponsors and OGC Staff) to decide the structure of the challenge and criteria for selecting finalists, winners and tie breaking.

OGC Pilots apply and test OGC standards in real world environments. Pilot projects are an opportunity for users to understand how to best address their requirements using standards-based architectures. Pilots demonstrate key aspects of the system identified in the Concept Development phase, including the development of key data models and critical workflows to deliver, use, and visualize data.

A Pilot evaluates the feasibility of implementing a standards-based architecture and provides valuable requirements for defining and developing solicitations or tenders for implementation of an operational system. Pilots are, in contrast to higher TRL Operational Exercises, located at TRL 4-6. Thus, Pilots usually work with prototypes or pre-production products that are explored in realistic scenarios. Pilots do not have the goal to deploy technology in real world environments.

A pilot unites technology users with technology solution providers in a fast-paced collaborative prototyping environment to test and evaluate implementation of existing or candidate standards. Pilots serve as an incubator to prioritize, encourage, and accelerate the pace at which standards-based capabilities are deployed to improve interoperability within a specific domain or user community.

Special emphasis in pilots is on demonstrating and validating the capability of standards-based practices to address real world scenarios provided by the user community. Pilot initiatives run the whole gamut of initiative phases. Pilots provide cost-sharing funds and are managed by the COSI TEAM. Pilots are required to deliver their results as Engineering Reports and often in various forms of outreach material. With few exceptions, Pilots have a typical duration of the agile development phase between 3 and 6 months.

OGC Plugfests are initiatives where vendors cooperatively test (and possibly refine) their OGC standards-based products in a hands-on engineering setting. Plugfests, located at TRL 6-8, are used to (1) assess the degree to which different products in the marketplace interoperate based on their implementation of OGC standards and (2) advance the interoperability of geospatial products and services based on OGC standards in general or within specific communities.

In a Plugfest OGC provides a neutral environment in which developers and data suppliers work together to validate the ability of their products to interoperate with other offerings implementing the same OGC standard(s). Plugfest goals can include:

An OGC Plugfest does not certify any combinations of OGC implementing or compliant products will operate error free or guarantee 100% interoperability. A Plugfest is not intended to provide a compliance suite for all portions of all available standards that are used in a Plugfest.

The phases of a Plugfest are depicted in [img-Plugfest].

The Call for Participation usually includes the following requirements:

Plugfests are often short duration initiatives that do not execute all initiative phases in full detail. Instead, Plugfests often have no Call for Sponsors, do not necessarily provide cost-share opportunities for Participants, and blend kickoff, agile development, and demonstration into a single physical meeting.

Plugfests are managed by the COSI TEAM and can be opened to non-OGC members. Plugfests are not required to deliver a formal Engineering Report. Instead, Plugfests usually share results within the group of Participants exclusively.

Operational Exercises (OpEx) target the upper end of the TRL scale at levels 7-8. They focus in particular on the viability of standards and technologies in operational environments where practitioners must fulfill critical roles and responsibilities for mission success. OpEx events validate products, plans, policies, agreements and procedures against real user activities in what are as close as possible to real operational settings. OpEx begin with market-ready products that implement technically proven OGC standards and evaluate whether they can significantly improve out-in-the-world mission performance. The scale and complexity of OpEx may range from small-scale drill-like exercises that test a single, specific function within one organizational entity, to large-scale multi-organizational, multi-jurisdictional, multi-discipline exercises.

OpEx initiatives run the gamut of initiative phases. OpEx are managed by the COSI TEAM, may have agile development phases ranging from 3 to several months, and generally include significant components of organizational outreach and user training. They include significant cost-share opportunities for all Participants to offset the substantial requirements of event preparation. OpEx are open to non-OGC member organizations. OpEx results are captured in Engineering Reports, Best Practice proposals, and possibly Change Requests.

An Interoperability Experiment (IE) is an initiative primarily led and executed by OGC members and facilitated by OGC staff. IEs, located at a rather wide span of TRL 3-7, have technical objectives that furthers OGC innovation by addressing requirements identified by members.

An IE is not funded by sponsors. Instead, members play the role of supporters, providing personal to lead the initiative with support from OGC staff. All Participants' efforts, including travel, is viewed as voluntary and supported as in-kind contributions of the participating member organizations. Most initiators provide human resources to help run the initiative or run the scenarios that are documented in the IE concept.

IEs do not implement all initiative phases, as they do not perform Calls for Sponsors or formal Calls for Participation. Instead, IEs use an informal Call for Participation that is announced through OGC communication channels.

IEs are required to deliver their results in formal Engineering Reports. IEs usually focus on a specific topic or technology and run between 6 to 12 months.

The OGC Testbed is an annual research and development program that explores geospatial technology from various angles. It takes the OGC Standards Baseline into account, though at the same time allows exploration of selected aspects with a fresh pair of eyes. The OGC Standards Baseline is the complete set of OGC Member approved Abstract Specifications, Standards (including profiles and extensions), and Community Standards. The Testbeds integrate requirements and ideas from a group of sponsors, which allows leveraging symbiotic effects and makes the overall initiative more attractive to both Participants and sponsoring organizations.

Testbeds emphasize the evaluation of what should be in a specification, how the specification should act, and how specification-based software should respond. While development is done during testbeds in terms of defining, documenting, and distributing specifications and in terms of developing prototypical software that exercises the specification, this development is generally along the lines of proof-of-concept rather than deliverable software.

Testbeds bring multiple sponsors together with hundreds of Participants. Testbeds go through all phases depicted in Figure 5 and usually run over an annual period with six to nine months of agile development time. The regular schedule of Testbeds allows potential sponsors to plan and properly research interoperability topics that they consider important to bring to the initiative. Managed by the COSI TEAM, Testbeds are run in multiple parallel threads with a dedicated architect per thread and an initiative architect overseeing the initiative. Many ERs can come out a testbed (20+), requiring special coordination with the Standards Program to move the ERs through the OGC TC approval process.

Engineering Services can have different focus and embodiment. The following list describes the range of Engineering Services. Thus, Engineering Services include but are not limited to:

The Engineering Services described above require a number of roles to be covered. These roles can be applied to any type of activity listed above. Engineering Services are usually executed in individual projects, always with the goal to further the use of OGC standards and benefit the OGC membership. A single project may make use of any number of roles as described below.

The OGC will follow principles of service engagement and operation as defined below.

OGC subsidiaries also apply these principles according to the laws, customs, and procedures of their respective regions.

All COSI Initiatives are announced to the OGC membership before the initiative begins. The pipeline of initiatives will be briefed to the OGC Planning Committee (PC) at each quarterly PC Meeting. Working Groups (WG) whose scope overlaps with the subject of an COSI initiative will be notified of the scope and potential deliverables of the initiative by the COSI Initiative Manager via OGC mailing lists or briefed at a Working Group meeting.

Every initiative shall have its own landing page available at the OGC website. The page shall be created before or during the concept development phase. The page will capture:

The OGC provides a framework that enables overall coordination between OGC Staff, OGC COSI TEAM, Sponsors, Participants, and other TC/PC Members as required. Initiative management includes the following activities.

In general, the Participant Agreements will not require delivery of any component source code to OGC. What is delivered instead is the behavior of the component installed on the Participant’s machine and the corresponding documentation of findings, recommendations, and technical artifacts as contributions to the initiative’s Engineering Report(s).

In some rare cases, a Sponsor might expressly require a component to be developed under open-source licensing, in which case the source code would become publicly accessible outside the initiative as a by-product of implementation.

Engineering Reports are member-privileged information and are not released outside of the membership unless a) the release is approved by OGC Staff for limited, non-public distribution or b) the document is made public by a motion and vote in the OGC Standards Program.

Initiatives shall be open to OGC members as observers without exception. OGC members can observe any initiative free of charge. Non-member organizations are invited to join initiatives as observers at a fee. Any organizations can make a request to join an initiative with observer status at any point after the initiative has been announced. Depending upon sponsor requirements, there may be limitations on what data may be viewed by observers.

The technical deliverables of an initiative shall not be construed to have any official status within the OGC. Specifically, documents that are generated within an initiative shall not be referred to as anything other than Engineering Reports (ERs). Status other than that can only be conferred by action of the OGC Technical and Planning Committees.