Skip to content

Commit f563063

Browse files
finos-adminfinos-admin
authored
Merge pull request finos#22 from finos/program-removal-rfc
Program Deprecation RFC - CLOSED
2 parents d5b2f77 + 70b11a6 commit f563063

File tree

1 file changed

+176
-0
lines changed

1 file changed

+176
-0
lines changed

‎rfcs/202001-rfc-program-removal.md

+176
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,176 @@
1+
2+
# Foreword
3+
4+
The purpose of this document is to propose simplifications to the governance of FINOS projects. We’ll discuss several issues with the existing governance structure and propose a simplified structure reducing hierarchy and bureaucracy.
5+
6+
7+
# Motivation
8+
9+
When the Symphony Software Foundation was reorganized as FINOS in April 2018, a governance structure for collaborative community projects was instituted. Projects and working groups (now collectively known simply as “projects”) were organized into high-level “programs” grouping projects focused on the same problem domain (e.g. Data Technology) or technology (e.g. Symphony).
10+
11+
Programs were designed to be self-governing, managed by a Program Management Committee of contributors to the projects within each program. Programs were required to abide by the high-level governance requirements of the FINOS Program Governance Policy (PGP) and to adopt a Program Operations Policy (POP) setting out their own particular operational rules. (Most adopted the “standard” POP recommended by the Foundation.)
12+
13+
This governance structure was largely borrowed from other open source foundations with mature projects produced by many active contributors experienced with open source collaboration. FINOS is different: our members are still new to open source collaboration and many FINOS projects are experimental or less mature. For many participants, the projects they contribute to are not essential to their daily work, so participation in FINOS governance is extra work with little reward. Strict requirements to constitute a PMC, hold meetings, and report regularly on program activity can be burdensome or pointless for programs whose projects are loosely connected and immature.
14+
15+
Additionally in July 2019 the Board of Directors approved a revision of the project lifecycle which identified objective criteria of quality, activity and viability for projects to transition into incubating, active and archived state. The goal was to provide a meta-roadmap for each project to become a successful pan industry open source effort while allowing a clear differentiation (for consumers primarily and for contributors) between nascent (incubating) and mature (active) projects. Like in most OSS Foundations, the project lifecycle should have a central role in the project taxonomy.
16+
17+
18+
# Background
19+
20+
The table below details how the existing governance structure has failed to operate as expected:
21+
22+
23+
<table>
24+
<tr>
25+
<td><strong>Expectations</strong>
26+
</td>
27+
<td><strong>Experience</strong>
28+
</td>
29+
</tr>
30+
<tr>
31+
<td>Programs are self-governing on technology and lifecycle matters
32+
</td>
33+
<td>Programs have become a governance overhead for FINOS and PMCs
34+
</td>
35+
</tr>
36+
<tr>
37+
<td>PMCs are in charge of nurturing their own Projects through the lifecycle
38+
</td>
39+
<td>PMCs are not mature or engaged enough and responsibility falls on FINOS
40+
</td>
41+
</tr>
42+
<tr>
43+
<td>Programs consolidate common activities around a theme/business problem
44+
</td>
45+
<td>Projects within programs are often loosely related. Concept of programs is a barrier of entry for new contributors.
46+
</td>
47+
</tr>
48+
<tr>
49+
<td>Programs are a governance only structure
50+
</td>
51+
<td>Program quickly got conflated within the FINOS messaging, which became more complex, and effectively became a strong partition of the project portfolio which limits organic evolution and growth in new areas.
52+
</td>
53+
</tr>
54+
<tr>
55+
<td>Membership to a PMC is a highly regarded responsibility and incentive for contributors to take a leadership role
56+
</td>
57+
<td>Only few PMCs have been functional with their members taking an active role
58+
</td>
59+
</tr>
60+
</table>
61+
62+
63+
64+
# Proposal
65+
66+
67+
68+
1. **Do away with programs and PMCs**: Projects will live at top level. They can still be categorized around similar themes and areas of interest in Github (theming / tagging) and other web properties.
69+
2. **FINOS approval role in software projects**: FINOS team approves new software projects and lifecycle transitions, based on objective criteria of [Incubating](https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530363/Incubating) and [Activation](https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530376/Activation). An appeal process to the Board is provided to contributors and community members to ensure impartiality and appropriate checks and balances.
70+
3. **Board input can be optionally requested**: FINOS team can decide to bring projects to the Board for approval into incubation (contribution) or other lifecycle transitions (activation/archival), to ensure initial industry wide buy-in as well as appropriate validation of the maturity state of a project. Board approves transition of incubating projects to “active” state when they demonstrate the required level of maturity.
71+
4. **Clarify Foundation focus and investments**:** **FINOS focuses on “coaching” incubating projects, while focused “marketing” efforts on active projects. In this sense, FINOS team’s open source coaching is directed more towards incubating projects, while marketing investment is directed more towards active projects (the crown jewels).
72+
73+
The expected benefits of this simplification are as follows:
74+
75+
76+
<table>
77+
<tr>
78+
<td><strong>Benefit</strong>
79+
</td>
80+
<td><strong>How?</strong>
81+
</td>
82+
</tr>
83+
<tr>
84+
<td>Drive allocation of FINOS resources
85+
</td>
86+
<td>Marketing focus only for “active” projects. Coaching / support focus for “incubating” projects.
87+
</td>
88+
</tr>
89+
<tr>
90+
<td>Reduce contribution friction
91+
</td>
92+
<td>FINOS can approve new “Incubating” projects directly, removing need for PMC approval or other governance process
93+
</td>
94+
</tr>
95+
<tr>
96+
<td>Reduce governance overhead
97+
</td>
98+
<td>Remove need for aggregated quarterly program-level reporting. Projects can report in a largely automated and independent fashion.
99+
</td>
100+
</tr>
101+
<tr>
102+
<td>Avoid speculative projects
103+
</td>
104+
<td>To promote sustainability and resource stewardship, FINOS will heavily validate initial buy-in from Community and board on “industry-wide” efforts (e.g. standards), thus promoting focus on valuable and viable efforts
105+
</td>
106+
</tr>
107+
<tr>
108+
<td>Drive banks’ member engagement
109+
</td>
110+
<td>For industry-wide projects (e.g. standards), FINOS will require bank SME engagement to establish projects
111+
</td>
112+
</tr>
113+
</table>
114+
115+
116+
117+
# Implementation
118+
119+
Implementation of these changes requires changes to the following FINOS governing documents:
120+
121+
122+
## Policies
123+
124+
125+
126+
* **Bylaws**
127+
* Section 4.1(b)(ii): remove reference to Programs (and working groups)
128+
* Section 6.2: remove this section entirely
129+
* The **Program Governance Policy** will be eliminated entirely. None of its requirements are necessary once programs are eliminated.
130+
* The **Program Operations Policy **will be eliminated. The following provisions should be adapted and moved to a separate FINOS policy (e.g. a “Project Operations Policy”):
131+
* Section II(C), setting out the procedure for approving new projects
132+
* Most of Sections III (Collaborative Principles) and IV (Projects) can be moved to the Community Handbook as statements of best practices for operating a project, but need not be strictly required. Section III(A)(a), requiring projects to enforce FINOS IP policies, is unnecessary because the Community Handbook already addresses these issues and FINOS staff enforces the IP policies.
133+
* The **IP Policy** will be revised to remove references to Program Operations Policies and to add the requirement of board approval for standards projects.
134+
* The **Trademark Guidelines** will be revised to remove references to programs.
135+
*
136+
137+
138+
## Web Properties
139+
140+
141+
### Messaging and Web properties
142+
143+
The removal of Programs will allow centering the FINOS messaging and web properties around:
144+
145+
146+
147+
1. Project Lifecycle: Active projects will be given central visibility on website, project catalog and other FINOS web properties. Incubating project will be listed in the project catalog and organized in a simplifies taxonomy for easier discoverability
148+
2. Functional taxonomy: With Program removed, FINOS will be able to implement a multi-dimensional taxonomy (e.g. tagging) allowing to simplify discovery of FINOS projects based on their functionality and / or position in the financial stack. This taxonomy will be validated with the Community and then implemented across web properties
149+
3. User centric messaging: FINOS web properties will be restructured to put the different target personas (consumers, contributors, etc.) front and center and enable discovery of high value projects solving problems for specific personas.
150+
151+
152+
### Source Code repositories
153+
154+
The process of consolidation of source code repositories into the main FINOS Github Org is expected to continue with the removal of programs. Repositories will be tagged appropriately to reflect the functional taxonomy (#2 above) and optionally map into the user centric messaging (#3). The FINOS catalog will be updated accordingly.
155+
156+
157+
### Wiki
158+
159+
The Wiki is currently organized around the Program construct. Whether the wiki remains on Confluence or moves to Github, a major wiki content overhaul is to be expected to align to the new governance:
160+
161+
162+
163+
* The Community Handbook will be revised throughout to remove references to programs, incorporate the new procedures for lifecycle transitions listed above, and incorporate elements of the standard POP.Remove Program structure and align to functional taxonomy above
164+
165+
166+
## Process
167+
168+
169+
170+
1. **Early Jan:** Internal review (AaronW, Tosha, Rob, Gab, James)
171+
2. **Mid Jan:** M&G Committee review
172+
3. **Mid Jan: **Community RFC starts
173+
4. **Late Jan: **Board approves a “blanket” resolution giving FINOS team green light to proceed
174+
5. **Early Feb:** Community RFC end and comments are incorporated
175+
6. **Feb - April: **Operationalization
176+
7. **Late April: **Board final policy approvals / cleanup

0 commit comments

Comments
 (0)