1. 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

2. 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

3. 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!

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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