Completed by: Yin Ding 

Submitted to TAC Mail List: -

Presented on TAC Weekly Call: TBD

Below is a self-assessment submitted by TSC Chair/Maintainers of the Project. Comments/questions/feedback is welcome either a) in the Comments at the bottom of the page or b) during the TAC call when information is presented

Stage 1: At Large Projects 

Stage 2 and Stage 3 Projects also requested to complete this section, as PLD acceptance criteria requires meeting current as well as prior stage requirements

Stage 1 Criteria (from the PLD)

Meets / Needs Improvement / Missing / Not Applicable

Supporting Data (if needed, include links to specific examples)

2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations


@Tina Tsou

Fukano Haruhisa 

The typical IP Policy for Projects under the LF Edge Foundation is Apache 2.0 for Code Contributions, Developer Certificate of Origin (DCO) for new inbound contributions, and Creative Commons Attribution 4.0 International License for Documentation. Projects under outside licenses may still submit for consideration, subject to review/approval of the TAC and Board.


  • The Akraino project has an "upstream first" policy. All Akraino Blueprints and Feature projects that contribute to upstream projects must complete the Upstream Dependency Matrix. The tables should be completed at project induction time (for new projects) and refreshed at release time (for existing projects). As of R4 and onward (Releases), in order to build a "stable Release" is a release which Downstream and Community can rebuild after a certain long period of time), Upstream will need to specify upstream repositories completely and with corresponding version/branch information. The list of each Blueprint Upstream Dependendency Matrix and Upstream Project information can be viewed at:

Upon acceptance, At Large projects must list their status prominently on website/readme


Stage 1 Projects, please skip to Additional Information Requested from All Projects

Stage 2: Growth Stage

Stage 3 Projects also requested to complete this section

Stage 2 Criteria (from the PLD)

Meets / Needs Improvement / Missing / Not Applicable

Supporting Data (if needed, include links to specific examples)

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.


Within Akraino, there is currently

Document that it is being used in POCs.


Each Blueprint (Integration) project is required to submit the followng set of  Documents:

  1. API description, 2. Architecture description, 3. Datasheet (one page Technical summary), 4. Installation Guide, 5. Release notes, 6. Test description. The deployment status of the Blueprint, being PoC, Demo or Commercial is presented/indicated in the Blueprint Architecture document.

Demonstrate a substantial ongoing flow of commits and merged contributions.


There had been more than 600 committs, by more than 60 contributors over more than 30 repositories. For the latest status/indications on the respective categorie(s), please use the LFX Insights Analytics tool:

Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan.


There have been more than 17.00K builds. For the latest status/indications on the respective categories, please use the LFX Insights Analytics tool:

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


The previously reported undertakings for high-level co-operation between some of the Akraino Blueprints as e.g. ELIOT and EdgeX Foundry remains.  The above also applies for the interaction/use of LF Edge EVE and Fledge (e.g. Akraino Blueprint IoT Camera maintenance Blueprint). The initiated by the Akraino API TSC Sub-committee work on assessing the room for potential co-operation among Akraino Blueprints and Development Projects remains and it is also set as part of the Akraino inter-operability Strategy Goals for 2023. Nevertheless, it is important to also explicitly state, that the Business Objectives and prioroties are set by (and within the Companies that had submitted and drive the Blueprints and respectively allocate their internal resources and set the related Budget for those resources to participate). 

Stage 2 Projects, please skip to Additional Information Requested from All Projects

Stage 3: Impact Stage


Meets / Needs Improvement / Missing / Not Applicable

Supporting Data (if needed, include links to specific examples)

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.


The Akraino Project Community Guiding Principle is to operate transparently, openly, collaboratively, and ethically. All (Akraino) Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders. The structure of the Akraino Technical Community consists of multiple projects and a Technical Steering Committee (TSC), with 20 members (with few new members elected in 2022), that spans across all projects and with representatives from variety of CSPs (Communication Service Providers) Companies. For detailed information on the Akraino TSC Members and the companies they represent, you may look at the:

Have a documented and publicly accessible description of the project's governance, decision-making, and release processes.


Akraino Community Governance

The Akraino Community functions as an Open Source Project, with a set of rules and leaders elected and approved from within the participants of the project.

The following serve as the official sources for Akraino Governance.

Akraino Project Lifecycle States and Reviews

Akraino projects’ life cycles defines five (5) states that projects goes through. A project lifecycle may extend across multiple projects and Akraino releases. The procedure of moving from one state to the next one is independent from the Akraino Release lifecycle and the pace depends on each individual project. In order to effectively review Project progress, four (4) Reviews are built-in to the project life cycle, namely, Proposal, Incubation, Mature, Core (Archived Project state can be assigned for multiple reasons. Either project has successfully been completed and its artifacts provide business values, or project has been cancelled for unforeseen reasons (no value anymore, technical,  etc.). Project in any state can be Archived through a Termination Review.


Akraino Technical Community Document - For detailed and/or additional insight information on the Akraino Technical Community Document description, you may look at:

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.


Please see below an example from LFX Insights Analytics tool about Akraino. Please note that the presented outcome of the selected categories may change depending on the selected period that the information is requested about.

Demonstrate evidence of interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects).


As indicated previously (above), there are several initiatives for co-operation with other LF Edge Projects  as e.g. EVE (as an Operating System) and LF Edge Fledge (as a Platform) Projects by Akraino ELIOT as well as EdgeX Foundry Project. The initiated development for inter-operabiity is part of the respective Blueprints own internal Development Plan, allocated resources and defined Business objectives and priorities.

Adopt the Foundation Code of Conduct.



Explicitly define a project governance and committer process. This is preferably laid out in a file and references a and file showing the current and emeritus committers.


The information input on Akraino Poject Governance provided previously above.

Technical and release decisions for a project should be made by consensus of that project’s Committers.  If consensus cannot be reached, decisions are taken by majority vote of a project’s Committers.  Committers may, by majority vote, delegate (or revoke delegation) of any portion of such decisions to an alternate open, documented (wiki), and traceable decision making process.Committer Lifecycle. Initial Committers for a project will be specified at project creation. Committer rights for a project are earned via contribution and community trust. Committers for a project select and vote for new Committers for that project.. New Committers for a project should have a demonstrable established history of meritocratic contributions. In the event that a project has no active committers (e.g., due to resignations, etc.), the TSC may appoint an interim Committer from a project’s active Contributors. This term shall last until the next release date, after which time the Committer must stand for election from amongst other Committers on the project to maintain his or her status.  In this special case, approval requires a majority of committers who respond within two weeks. If no one responds by the deadline, then the committer status is approved. This provision allows a project to continue development following an unexpected change in personnel.

The method by which the TSC appoints an interim Committer is first by request to the Akraino-TSC email list indicating the request to appoint an interim Committer for a project.  After the reception of such an email, the normal TSC decision process applies.

Have a public list of project adopters for at least the primary repo (e.g., or logos on the project website).


On a list of Project Adopters, please visit the LF Edge website related to Akraino that provides information on the Integration projects and involved adopters. The link to LF Edge website related to Akraino is: and specifically, as part of the Akraino latest Release, namely R5, please visit thewebsite with the following link:

Additional Information Requested from All Projects

Additional Information Requested from All Projects

Supporting Data (if needed, include links to specific examples)

Intention for the upcoming year (Remain at current stage OR advance towards the next Stage)

The discussion outlining the priorities for R8 are set on the Agenda of the Akraino Spring 2023 Technical meeting. The scope for future work of Akraino API Sub-committee for Blueprints inter-operability and Akraino Security Sub-committe objective for automation between Akraino Security and Bluval (Blueprint Validation) process for 2023 is also part of the Akraino Spring 2023 Technical meeting.

Include a link to your project’s CommunityBridge Insights page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add color to the numbers and graphs we will see on Insights.

How many maintainers do you have, and which organizations are they from? (Feel free to link to an existing MAINTAINERS file if appropriate.)

Maintainers are at Akraino Blueprint and Development project level and therein varies accordingly. You can monitor and follow through the LFX Insights -
What do you know about adoption, and how has this changed since your last review / since you joined the current Stage? If you can list companies that are end users of your project, please do so. (Feel free to link to an existing ADOPTERS file if appropriate.)This again varies among Akraino Blueprints and Development projects. Please see at LFX Insights -
How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)The targets in terms of Blueprints evolvement/maturity via the above indicated 4 (four phases, "Archived" phase not included/counted) and adding new Blueprints/Development projects had been impacted by the Covid-19 in 2021 in terms that some of the Blueprints had not added any changes/development for R5 and stayed at the R4 level.
What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?The focus is on the coming Akraino R6 and outlining the type and use of APIs by all the Akraino Blueprints and Development Projects for 2022 in order to outline a potential plan and scope for possible inter-operability among the Akraino Blueprints/Development Projects and enhanced automation between Akraino Security and Blueprint Validation processes.
How can LF Edge help you achieve your upcoming goals?LF Edge can provide an insight on synergy between existing Technology Architecture Specifications from various SDOs and Open Source Communities, e.g. 3GPP, , ETSI MEC, TM Forum ODA LF ONAP, LFN Anuket, ONAP, CNCF, O-RAN Alliance, Digital Twins Consortium, IoT, etc.,  and identify a Common Architecture Framework that  all LF Edge Projects can follow and through compliance to that Common Architecture Framework achieve and inter-operatibility and scalability among the LF Edge Projects.
Do you think that your project meets the criteria for the next Stage?Yes.
Please summarize Outreach Activities in which the Project has participated in (e.g. Participation in conferences, seminars, speaking engagements, meetups, etc.)Participation at various Conferences as ONES and Edge Computing World and varios guest speakers from various Companies and SDOs as ETSI MEC, ETSI NFV, Verizon, Google, HPE, Telefonica, CNCF TUG etc.,
Are you leveraging the Technical Project Getting Started Checklist? If yes, please provide link (if publicly available).

Akraino benefits from the following Getting started Project description.

  1. Getting started with Akraino

2. Getting started with Akraino Project: Process, Project Review, recommend and Documentation

Process, Project review and recommend sub-committee: Finalize request Templates for Blueprint and feature project, document to allow developers to get started. Develop and evolve the process by which blueprint and feature project proposals are reviewed, and ultimately approved with recommendation required documentation.Template 1 - Use case template, Template 2 - Blueprint family template, Template 3 - Blueprint species template

  • No labels