You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »


Status

  • Presented to the TAC
  • TAC Project Review:
    • Subgroup Review Meeting: 
    • Subgroup Readout: 
  • TAC Vote Approved
  • Governing Board Vote Approved

Project Resources



Stage 3: Impact Stage

Definition

The Impact Stage is for projects that have reached their growth goals and are now on a self-sustaining cycle of development, maintenance, and long-term support. Impact Stage projects are widely used in production environments and have large, well-established project communities with a number of contributors from at least two organizations.

Examples

  1. Projects that have publicly documented release cycles and plans for LTS.
  2. Projects that have themselves become platforms for other projects.
  3. Projects that are able to attract a healthy number of committers on the basis of its production usefulness (not simply 'developer popularity').
  4. Projects that have several, publicly known, end-user deployments.

Expectations

Impact Stage projects are expected to participate actively in TAC proceedings, and as such have a binding vote on TAC matters requiring a formal vote, such as the election of a TAC Chair. They receive ongoing financial and marketing support from the Foundation, and are expected to cross promote the foundation along with their activities.

Acceptance Criteria

To graduate from At Large or Growth status, or for a new project to join as an Impact project, a project must meet the Growth stage plus Impact stage criteria:

Stage 2: Growth requirements:

  • Development of a growth plan (to include both roadmap of projected feature sets as well as overall community growth/project maturity), to be done in conjunction with their project mentor(s) at the TAC.
  • Document that it is being used in POCs.
  • Demonstrate a substantial ongoing flow of commits and merged contributions.
  • Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan.
  • Demonstrate evidence of, or a plan for, interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects).
  • Since these metrics can vary significantly depending on the type, scope and size of a project, the TAC has final judgement over the level of activity that is adequate to meet these criteria.
  • Receive a two-thirds vote of all TAC representatives that do not abstain the vote and a majority vote of the Governing Board to move to Growth Stage.

Stage 3: Impact requirements:

  • Have a defined governing body of at least 5 or more members (owners and core maintainers), of which no more than 1/3 is affiliated with the same employer. In the case there are 5 governing members, 2 may be from the same employer.
  • Have a documented and publicly accessible description of the project's governance, decision-making, and release processes.
  • Have a healthy number of committers from at least two organizations. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project.
  • Demonstrate evidence of interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects).
  • Adopt the Foundation Code of Conduct.
  • Explicitly define a project governance and committer process. This is preferably laid out in a GOVERNANCE.md file and references a CONTRIBUTING.md and OWNERS.md file showing the current and emeritus committers.
  • Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
  • Other metrics as defined by the applying Project during the application process in cooperation with the TAC.
  • Receive a two-thirds vote of all TAC representatives that do not abstain the vote and a majority vote of the Governing Board to move to Impact stage. Projects can move directly from At Large to Impact, if they can demonstrate sufficient maturity and have met all requirements.


Compliance with Requirements

Stage 2: Growth

RequirementEvidence
Growth plan

The Fledge project and community plans to create a strong ecosystem around Fledge to attract more users and stimulate community growth by:

The Fledge community has been growing steadily over the years incorporating a diverse set on contributors from various organizations.

  • Recently the Fledge TSC was expanded its voting members to incorporate a diverse representation of organizations.
  • Growing attendance from a variety of users and contributors.
  • Demonstrations of new features.

Beyond the LF Edge community, Fledge focuses on industrial use cases so one of the primary goals is to meet the industrial communities outside of LF Edge where they do.

Two main industrial communities in energy verticals have been the main focus but not limited to:

  • LF Energy: is an open source foundation that focuses on power systems hosted within the Linux Foundation. 
  • OSDU (Open Subsurface Data Universe): The OSDU Forum is developing an open source, standards based, technology agnostic data platform. Primarily focuses on oil and gas and renewables.

See more under Growth Plan.

Used in PoCs

Several public Use Cases cases have been documented and implemented on PoCs.

New ones include:

Substantial ongoing commits and contributions

Tom looking into mappings: LFX Insights (Last 5 Years)

Community participation meets growth plan goals

Two main industrial communities in energy verticals have been the main focus but not limited to:

  • LF Energy: is an open source foundation that focuses on power systems hosted within the Linux Foundation. 
  • OSDU (Open Subsurface Data Universe): The OSDU Forum is developing an open source, standards based, technology agnostic data platform. Primarily focuses on oil and gas and renewables.

Achievements

FledgePOWER

FledgePOWER is a multi-protocol translation gateway for power systems based on the industrial IoT LF Edge project. This cross foundation collaboration between LF Edge and LF Energy ensures strong cooperative governance and technical alignment between the two communities. FledgePOWER aims to build and grow a community of end-users, developers, utilities, and other players to collaborate to solve current and future challenges in the energy space. Further information can be found on:

OSDU Edge

OSDU has selected Fledge and EVE as the edge stack architecture for OSDU EdgeMeeting OSDU Edge requirements with LF Edge projects mitigating lock-in through vendor-neutral governance and interoperable solutions. 

The architecture was successfully demoed to OSDU members in October, 2021.

See more under Growth Plan.

Evidence of interoperability, compatibility with other LF Edge projects

The latest Fledge collaboration includes:

More information on past and ongoing collaboration can be found here: Cross-LF Edge Collaboration and here Fledge Roadmap 2020/2021.

Stage 3: Impact

RequirementEvidence
Governing body of at least 5, no more 1/3 from same employer

The Technical Steering Committee (TSC) has expanded its voting members to 6 as follows:

  • Mark Riddoch - Dianomic - Chair
  • Tom Arthur - Dianomic
  • Daniel Lazaro - OSIsoft now part of AVEVA
  • Benoit Jeanson - RTE
  • Robert Raesemann - Raesemann Enterprises
  • Mike Styer - Google
Documented governance, decision-making, release processes

Needs more?

The following documented processes are in place:

Healthy number of committers from at least two orgs

Tom looking into mappingsLFX Insights (Last 5 Years)

Evidence of interoperability, compatibility with other LF Edge projects

The latest Fledge collaboration includes:

More information on past and ongoing collaboration can be found here: Cross-LF Edge Collaboration and here Fledge Roadmap 2020/2021.

Adopt LF Code of conductThe Fledge community adheres to the LF Code of Conduct as described here: Code of Conduct
Explicitly define a project governance and committer process

The Fledge community has defined and documented the following Repository Approval Policy as well as the committer process here: CONTRIBUTING.md and project Governance.

Public list of project adopters

The Fledge Community welcomes contributions of all types; documentation, code changes, new plugins, scripts, just simply reports of the way you use Fledge or suggestions of features you would like to see within Fledge. A public list of project adopters can be found here.

>= 2/3 approval vote of TAC & majority of Governing Board



  • No labels