A 21ST CENTURY PROCESS LIGERS; Meeting the expectations and needs of today’s developers SIMPLIFICATION: Making our rules easier to read and less daunting REFACTORING: Making rules re-usable for multiple purposes

WHAT THE MARKETPLACE WANTS: 5 ingredients Offer modern developer-friendly tools and best practices to TC-like working groups Reduce barriers to participation and contributions Move to a continuous development model (incremental change releases) Enable seamless flow between concurrent code development and specification development, by a common community group: but under OASIS levels of good governance and a level playing field Allow for automatic extraction of APIs and protocol documentation from open code and ease the creation of specifications

Building a sustainable business model Open Source Availability + Open Standards Governance = interoperability. These are not enemies, these are the genetic ingredients of a hybrid. Do you use Github? Do you wish your APIs and protocols were formalized and recognized globally? In OASIS: you can keep using the tools you use, you can facilitate interoperability between multiple independent implementations, you can leverage industry-vetted rules and process, and you can do it in ONE PLACE. A ONE-STOP INTEROP SHOP!

WHAT’S A LIGER? Technical Committees Our existing primary product Governed by TC Process Mandatory public reviews Governed by current IPR Policy Modes like RF on RAND, NonAssert, etc. License binding at the end Existing TC Admin quality control SLAs Open Project Committees (“Ligers”) Open development style: rules are simpler, tools are more like a development environment Review by continuous input Different IPR: FOSS license terms Licensing binding at contribution time Still has OASIS technical assistance 4 4

WHAT’S A LIGER? Open Project Committees (“Ligers”) Technical Committees (product may be refined, but not changed) Open Project Committees (“Ligers”) Open development style: Typically async: meetings optional Simplified: more agile, less formal Simple approval voting Probably ‘releases’ not ‘specifications’ Core development occurs on forkable repo, not static uploads Different IPR: FOSS license terms Licensing binding at contribution time TBD: can finalized releases be placed into an OS path by adding OS-level reviews? 5 5

LIGERS (“project committees”) Early versus late IPR commits Project starts … Contributions made, edited … Outputs approved Licensed EVERYWHERE on the timeline Licensed HERE Open Project Committee rules TC Process and IPR

PROCESS REVISION: FIVE STEPS (1) TC Process simplification, plus usual improvements (2) Weed some admin details out of TC Process, replant them in posted TC Admin guidance (3) Extract “General Rules” for re-use in multiple places (4) Open Source Project Committees (Liger concept) (5) Reconciling ANSI, Open Repo, other floating pieces of rules – rule rationalization clean-up Simplify Weed out Generalize Add Products Rationalize The more bloated and complex your rules are, the more annoyed your customer is

Taking a Critical Look at the TC Process Can we: Make it shorter? Make it less daunting? Cleaner, with fewer hard stops? Simplify Weed out Generalize Add Products Rationalize

But Proceeding Carefully Changes must not harm our standing with other orgs: ISO, JTC 1 & other de jure SDOs ANSI EU / MSP Simplify Weed out Generalize Add Products Rationalize

Our Approach Our approach: Reorganize to put the ‘good stuff’ first Remove “how” text; focus on “what” Remove steps that have outlived their usefulness Review how process would look if public reviews were optional Simplify Weed out Generalize Add Products Rationalize

Where Are we Now? So far: Concept draft of TC Process to identify areas of opportunity Reviewed for impacts on other policies Brought forward to Board Process Committee Simplify Weed out Generalize Add Products Rationalize

Step 1: TC Process simplification: plus the usual improvements process Simplify Weed out Generalize Add Products Rationalize 1 Definitions 2 Process 3 Spec progress 4 5 ANSI Open Repos The issues being discussed in Board Process now Our staff walk-through of the TC Process generated more possible improvements, which we’ll bring forward for committee discussion

Step 2: Weed out admin details, and place in TC Admin guidance Simplify Weed out Generalize Add Products Rationalize Today’s TC Process 1 Definitions 2 Process 3 Spec progress 4 5 ANSI Open Repos Existing Posted TC Admin guidance

Existing Posted TC Admin guidance AFTER Steps 1 and 2 Simplify Weed out Generalize Add Products Rationalize Today’s TC Process 1 Definitions 2 Process 3 Spec progress 4 5 ANSI Open Repos Existing Posted TC Admin guidance

Step 3: Reorder, and extract General Rules (like transparency) Simplify Weed out Generalize Add Products Rationalize General Process Rules 2 Process 3 Spec progress 4 1 Definitions 5 ANSI Open Repos Existing Posted TC Admin guidance

dot-orgs (Consortium in a Box) Other Projects (Ligers) What we have now: silos Simplify Weed out Generalize Add Products Rationalize Am I the same process as a regular TC, or a different one? If I’m not an OASIS-branded thing, can I use OASIS rules? So am I a method or a committee or what? TC Process ANSI Addendum Bespoke dot-orgs (Consortium in a Box) Other Projects (Ligers) Open Repos

General Rules: transparency, chairs, vote methods Re-factor for Re-Use Simplify Weed out Generalize Add Products Rationalize General Rules: transparency, chairs, vote methods TC Process ANSI Addendum Bespokedot-orgs (Consortium in a Box) Other Projects (Ligers) Open Repos

Step 4: Adding in Other Products Simplify Weed out Generalize Add Products Rationalize General Process Rules 2 Process No, we have not written the “Liger Committee” rules yet, just an outline Like TC Process, will need its own voting and membership rules. Simpler – but still member-oriented. Needs its own IPR rules too: somewhat like today’s Open Repo for TCs rules – MAY be able to re-use them. Will re-use the “general” rule components Coming to Board Process committee (or etc) this Autumn 3 Spec progress 4 1 Definitions ANSI Open Repos Consortium in a Box rules Open Project Committee rules Posted TC Admin guidance 18 18

Step 4: Adding in Other Products Simplify Weed out Generalize Add Products Rationalize General Process Rules 2 Process 3 Spec progress 4 1 Definitions ANSI Open Repos Consortium in a Box rules Open Project Committee rules Posted TC Admin guidance

MULTIPLE OFFERINGS Simplify Weed out Generalize Add Products Rationalize Technical Committees Our existing primary product Governed by TC Process Existing SLAs “Consortium in a Box” dot.orgs: Distinct corporate existence Negotiated rules and support Negotiated eligibility requirements Program/staff assistance Optional use of rule components General Process Rules 2 Process 1 Definitions 3 Spec progress 4 ANSI Open Repos Consortium in a Box rules Open Project Committee rules Project Committees (“ligers”) Simplified process, less formal Different IPR: commit at contribution time, aimed at open-source-native development Simpler model for publication Re-use of general rule components Posted TC Admin guidance

Step 5: Rationalization and clean-up Simplify Weed out Generalize Add Products Rationalize General Process Rules ? 2 Process 3 Spec progress 4 1 Definitions ANSI Open Repos Consortium in a Box rules ? Open Project Committee rules ? Posted TC Admin guidance

A 21ST CENTURY PROCESS Shorter and simpler -- especially on first read Supports multiple products with multiple licensing approaches Consistent with the habits of the market we’re in vs. when rules were written (1999) The more bloated and complex your rules are, the more annoyed your customer is