Apereo Incubation Process

Table of Contents:
Section 1 Incubation - An Introduction
Section 2 Benefits of Incubation and Endorsement
Section 3 Incubation Overview
Section 4 Core Process
Section 5 Exit Criteria
Appendix 1
Appendix 2

 

Apereo Incubation Process

Section 1. Incubation - An Introduction

1.1 The Apereo Foundation incubation process plays a significant part in the formative stages of the path from innovation to sustainability for a new software project or community. It supports a critical part of the software and community lifecycle, bringing the experience of those who have travelled the path before, successfully or unsuccessfully, to bear for the benefit of the new project, and the Apereo community as a whole. 

1.2 Some of the collective experience the incubation process channels is relatively hard-edged; the need for a consistent inbound and outbound licensing regime to manage intellectual property, for instance. Other areas, such as the development of sustaining communities around software artefacts, reflect specific experiences in specific contexts, and are far more difficult to codify. This is why our incubation process is, at core, concerned with scaffolding a systematic mentoring process, rather than simply laying down a set of "rules" to follow. 

1.3 The experience the Apereo Foundation represents is international and diverse. Participants in the broad Apereo community bring a range of experiences within higher education to the table; teacher, researcher, software developer and learning technologist, together with those engaged in institutional management or leadership. 

1.4 The Apereo incubation process is two-way: in addition to the benefits for the software or other community in question, incubation adds to the collective experience of the Apereo community as a whole. This is a key aspect of continuing to refine, extend and develop the support incubation offers to projects and software communities.

1.5 The objective of the incubation process is not to guarantee sustainability, but to ensure that a number of criteria determined by collective experience are met at a formative stage of development, before a project or community is approved as an endorsed Apereo project. The incubation process serves as an entry point for a project or community seeking to become an Apereo sponsored software community. 

1.6 Sustainability is not an abstraction, but a facet of the software or community lifecycle. A project that does not progress from incubation to become an endorsed Apereo project should not be considered a failure. There are a variety of reasons why this might happen, ranging from technical feasibility to lack of broader community interest. The process is designed to identify such issues and test the viability of a project from a number of perspectives at an early stage of its development. This outcome of the process acts to mitigate against an extended investment of resources by institutions or individuals where this is inadvisable. This, in itself, represents a significant benefit of incubation.

1.7 Incubating software communities and projects gain from the structure and resource the foundation provides. They are expected to reciprocate this support by advocating Apereo Foundation membership amongst their own community.

Section 2. Benefits of Incubation and Endorsement

2.1 Apereo is a membership organization of educational institutions and commercial entities that seek to “collaborate to foster, develop, and sustain open technologies and innovation to support learning, teaching, and research”. Participation in the Apereo Foundation and community brings a series of tangible benefits for an incubating project, ranging from access to the experience of others working in similar fields as mentors, through to Intellectual Property Rights (IPR) management, technical expertise, licensing, legal, meeting, and communications infrastructure.

2.2 Membership dues and volunteer effort provide the core resources for Apereo. The Foundation uses these resources to provide a framework of services and processes for Apereo software communities. To become an Apereo endorsed software community, a project must graduate our incubation process.  

2.3 Participation in the global Apereo community provides access to a range of potential global adopters and contributors, and to the outreach resources of the Foundation itself - for example, conferences and events spread across eight countries on four continents. Fundamentally, participation allows a project or community to become part of a larger network and gain the benefits of a network effect. This network is not confined to membership of the Apereo Foundation. We seek to build reciprocal relationships with other organizations with similar missions. This is at the heart of our close and developing  relationship with the ESUP-Portail consortium in France, the LAMP Consortium in North America, and our communities in Japan, South Africa, and Europe. Apereo is a powerful voice for international collaboration in education, supported by a culture of contribution and innovation.

2.4 A supportive incubation process, which acts to define and refine our core values, in addition to developing practical sustainable solutions for education, is an important part of developing and maintaining that culture.

Section 3. Incubation Overview

3.1 Proposal Submission: A community member or members may submit an Incubation Proposal to the IWG. An incubation proposal should be “sponsored” by two member organisations (“Sponsorship” in this sense, requires no financial commitment). Incubation Proposals are  published to the Apereo Announcements and Open lists, in addition to the Apereo Incubation Working Group (IWG) and Board lists. The IWG will discuss the proposal and recommend it be accepted as an Incubating Project or Unsponsored Contribution, or be declined. Reasons for this choice will be provided to the Apereo Board in a recommendation. 

3.2 The Apereo Board will approve this recommendation, reject it, or seek further clarification, The objective of this stage of the process is to secure community input, and to create reach consensus between the incubation working group and board. The Incubation Proposal may be for a new project or community to be developed under the auspices of Apereo or may be an existing external project or community seeking Apereo recognition. 

3.3 The IWG and Board decision will be published on the Apereo Announcements and Open Lists.

3.4 Members of any Apereo body considering an incubation request will be bound by the Apereo Foundation Conflict of Interest policy. This can be found in the Apereo bylaws at http://www.apereo.org/content/bylaws.

3.5 Approval: When a project is approved, and in consultation with the authors of the Incubation Proposal, the IWG:

3.5.1 Assigns a Mentor or Mentors
3.5.2 Establishes an approximate Incubation Timeline, in consultation with the incubating project. This is guidance only, and is intended to assist the IWG planning resource allocation across the incubation process as a whole.

3.6 Progress: The incubating project works with a mentor or mentors to record progress against the criteria set to exit incubation as an Apereo Endorsed project (see section four of this document for exit criteria). Mentors reports progress to the IWG at least once per quarter, or against milestones set on the Incubation Timeline. 

3.7 Progress will be reported through a template based on the incubation exit criteria (see section 5 of this process). This will be agreed with an incubating project or software community and linked to the description of the project or community on the Apereo website.

3.8 Review: IWG reviews incubating projects quarterly, or according to pre-determined points on the agreed Incubation Timeline and determines whether to recommend the project for sponsorship continue incubation or terminate incubation. These judgments will be based on the exit-criteria outlined in Section Four of this document. Such decisions will be arrived at consensually with the board.

Section 4. Core Process

This process describes how an Incubation Candidate or other Incubation Proposal would progress from submission to full acceptance as an Apereo Project.

4.1 Proposal Submission: A community member or members may submit an Incubation Proposal to the IWG. An incubation proposal should be “sponsored” by two member organisations (“Sponsorship” in this sense, requires no financial commitment). Incubation Proposals are  published to the Apereo Announcements and Open lists, in addition to the Apereo Incubation Working Group (IWG) and Board lists. The IWG will discuss the proposal and recommend it be accepted as an Incubating Project or Unsponsored Contribution, or be declined. Reasons for this choice will be provided to the Apereo Board in a recommendation. 

4.2 The Apereo Board will approve this recommendation, reject it, or seek further clarification, The objective of this stage of the process is to secure community input, and to create reach consensus between the incubation working group and board. The Incubation Proposal may be for a new project or community to be developed under the auspices of Apereo or may be an existing external project or community seeking Apereo recognition. Members of any body considering an incubation request will be bound by the Apereo Foundation Conflict of Interest policy.

4.3 The IWG and Board decision will be published on the Apereo Announcements and Open Lists.

4.4 Proposal Content: A proposal for admission to incubation is made to the IWG via at incubation[at]apereo.org[dot] This should contain the basic information listed in (a) to (j) below.  A proposal that relates to an existing Software Community is passed directly to the relevant Project Governance structure upon receipt by the IWG for consideration. The Chair of the IWG and Lead/Chair of the appropriate Software Community agree a means to progress the proposal as soon as is practicable.

4.4.1 The proposal would be expected to be less than 2 pages in length.

4.4.2 A proposal must contain: 

  1. A proposed name for the project, together with a brief explanation of why the project wishes to enter Apereo incubation, and how the project would benefit higher education.
  2. A short preface for the mailing lists, for use if the Project or Community is accepted
  3. A proposed Project Lead or Community Chair, with contact information
  4. Two or more organizational recommendations from representatives of members of the Apereo Foundation. 
  5. A list of the initial contributors for the Project or Community
  6. An overview of the aims of the Project or Community
  7. A technology overview if known
  8. An overview of any current user base or user community
  9. An overview of how the Project or Community relates to other parts of Apereo, if appropriate
  10. A pointer to any current information (for example, an existing Web site) 

4.5 Acceptance as an Incubating Project or Community: Once it has been accepted for incubation, a project or community may use Apereo provided technical resources. The Incubation Working Group will provide assistance with software infrastructure pieces and best practice. 

4.6 Post Acceptance and Foundation Next Steps: Once a project has been accepted for incubation, the following actions take place

4.6.1 The project officially becomes an “Incubating Project” or “Incubating Community” under the auspices of Apereo.

4.6.2 The IWG nominates one or more Mentors for the project. The Mentors act as a bridge between the IWG and the project.  In conjunction with the incubating project or community the Mentors establish an indicative Incubation Timeline and ensures that the project or community understands the exit criteria (see section five of this document). The timeline should be agreed with the IWG.

4.6.3 The IWG assists the incubating project in the initial start-up to use the Apereo resources described above, if appropriate. These resources should be set up in Apereo infrastructure unless the Incubating Project or Community and IWG decides otherwise.  Members of the IWG will create resources (svn, jira, wiki etc.) and access as required.

4.6.4 The IWG assists the incubating project in performing appropriate licensing, contribution, trademark, and other legal arrangements.

4.6.5 The IWG adds the project to the incubating projects space on www.apereo.org

4.7 Post Acceptance – Project or Community Next Steps: A Newly Incubating Project or Community then performs the following actions

4.7.1 Indicate that the project is in incubation (though not yet fully endorsed/supported by Apereo).

4.7.2 Display the Apereo incubating project logo to indicate affiliation.

4.7.3 Use Apereo infrastructure for development and collaboration unless an alternate infrastructure is agreed by IWG to be more appropriate.

4.7.4 Incubating projects and communities are encouraged to participate in Apereo conferences and other events. Time will be reserved in the principle conference schedule for “meet the incubators” session/s.

4.8 Periodic Review: Projects in incubation will undergo periodic reviews by the IWG as determined by the project incubation timeline that may have one of the following outcomes

4.8.1 The project will be recommended to the board or appropriate community governance structure as a fully endorsed Apereo project or community.

4.8.2 The project will remain in Incubation.

4.8.3 The project will be asked to become an Unsponsored Contribution due to lack of viable community.

4.8.4 The project will be asked to retire due to lack of progress. or the project discontinues its association with Apereo (by self-sponsoring or migrating elsewhere).

4.9 Promotion to full-fledged product

4.9.1 The project may be promoted to Endorsed Project or Software Community when it meets legal, governance, community, alignment and synergy together with the Infrastructure requirements outlined in section five of this document.  When these requirements are met the IWG will recommend to the board that the project be promoted to Endorsed Project status. Endorsement of a project requires a positive vote of the Apereo Board.

4.10 Termination of Project, Software Community Endorsement: Either the Apereo Foundation Board or Incubation Working Group may terminate recognition according to the following conditions

4.10.1 The IWG may vote to recommend termination of endorsement to the Apereo Board, which should discuss and vote on the issue at its next meeting. The Board is bound by Apereo bylaw to require a two-thirds majority vote in favor of termination.

4.10.2 The Apereo Board may vote to recommend termination of endorsement to the IWG, which should discuss and vote on the issue at its next meeting. The Board is bound by Apereo bylaw to require a two-thirds majority vote in favor of termination.

4.10.3 The Project Governance structure may vote to terminate recognition.

4.10.4 Once one of the above in voting procedures is completed, termination is effective at the second scheduled meeting of the Board or Committee that did not execute the vote, or in 90 days, whichever comes first. If the termination of endorsement vote is rescinded, termination is no longer effective. 

4.10.5 It is expected that an effort will be made to resolve any issues related to the sponsorship termination prior to the procedures being put in effect.

4.11 Conflict Resolution: The objective of the incubation process is to provide a supportive and transparent environment for nurturing new projects and communities. It is built around the development of consensus between appropriate bodies within Apereo: Board, Incubation Working Group, and, where necessary, governance bodies of existing software and other communities. Consensus will normally be created by communication and negotiation. Where this fails, mediation by institutional representatives external to the case in point will be solicited.

 

Section 5. Exit Criteria

The minimum requirements that a project must meet to exit incubation are set out below. Incubating projects and communities should work on fulfilling these requirements throughout the incubation process. Requirements are not set out in the order in which they should be undertaken, which depends on the context and requirements of any given project or community.

5.1. Legal

5.1.1 All source code, project materials, and other distribution elements should be properly licensed with an approved outbound license. See “Apereo Licensing Policy” https://www.apereo.org/licensing, as well as the requirements of the specific outbound license, for further details.

5.1.2 Appropriate licensing/copyright assertions and other notices, included in the overall distribution, codebase, and individual source code headers should be in place. Details are in “Implementing the Apereo Licensing Policy”, as well as the specific outbound license. No license-incompatible 3rd party dependencies, and no unlicensed code/dependencies should be included or redistributed anywhere in the code base.

5.1.3 Appropriate Contributor Agreements should be on file, including: Individual Contributor License Agreements (ICLAs) for all active/former contributors, Corporate Contributor License Agreements (CCLAs) for all employers with employees contributing, and Software License Grant Agreements (SGLAs) for any significant pre-existing bodies of work being contributed to the project.

5.1.4 The project or community name should be checked for trademark issues.  The Incubation Working Group will check project name against US patent and trademark. Descriptive names such as Calendar Portlet do not need to be checked.  Following is the link for doing a trademark search with the US Patent and Trademark Officehttps://www.uspto.gov/trademarks-application-process/search-trademark-da...

5.2. Community
​Demonstrate an active and diverse development or participant community. The Incubation Working Group will take a range of factors into account in judging progress in this area, including;

5.2.1 The level of community involvement, including: What is the number of participants? What level of participation is there? What activities do participants undertake or what artefacts have they created?)

5.2.2 The organization of the community, including: What roles are in place? Who occupies those roles? How do those roles interact among one another and with the community?

5.2.3 The operation of the community, including: What activities/events/artefacts are created/managed by the project to foster participation and development? How are decisions made?

5.3 Governance 
​A project governance structure should be created to oversee the project. Examples of open source software governance models are available from: 

5.4 Standard voting practices have been adopted. A non-binding example can be found at the JA-SIG Project Incubation: 

5.5 The project or community should have reviewed material from the Ethical OS Initiative. https://ethicalos.org/

5.6 The project has adopted a conflict resolution policy. An example is offered in this process (see Section 4.11 above).

5.7 Release plans are developed and executed in public by the committers.

5.8 At least one release has occurred during the Incubation process.

5.9 Alignment & Synergy
The Incubating Project should consider the use of other Apereo software where appropriate, and develop synergistic relationship with other Apereo projects wherever mutually beneficial. Evidence of consideration or adoption should be noted. 

5.10 Infrastructure
​Items 1 to 4 below should be in place for software projects and communities.

5.10.1 A software versioning and revision system is in place.

5.10.2 An issue tracking system is in place.

5.10.3 Mailing lists or other clear communications channels have been created and publicised.

5.10.4 Future plans, directions and objectives are articulated in a readily accessible format.

5.10.5 Project website is current, and contains instructions for installation and configuration.

5.11 Community Reporting
The project or community should have completed the software community health template (appendix 1)

Appendix 1: Incubation Process Glossary of Terms


Incubation Candidate - An Incubation Candidate is a project or community that wishes to apply for entry to the Incubation Process, but that may or may not meet all the criteria for admission.
 
Endorsed Project or Software Community - Offical Apereo project with an appropriate governance structure and supported by a community of users and developers. A software related project with more than one major release would normally be considered a software community.
 
Incubation Process - The Apereo Incubation Process is the process whereby open source software projects and communities are proposed, incubated, evaluated, progressed, and become full-fledged Apereo endorsed projects and communities as appropriate.  Software that relates to an existing project should normally be transferred to the existing project governance structure for incubation and governance.
 
Incubation Proposal -A proposal to allow a project or community to enter the incubation process as an incubating project. Such proposals will contain the names of two Organizational Sponsors that are Apereo Foundation members
 
Organizational Recommendations - In order for a project or community to enter incubation, it must have expressions of support for entry from two organisations which are members of the Apereo Foundation in good standing. No financial sponsorship or other resource is implied by such nomination. The nominated organizational representatives of the member organization should make such recommendations.
 
Incubation Timeline - An approximate duration for the incubation process, established with the incubating project by negotiation when it enters the incubation process. This is intended to be a realistic and conservative “guiding statement”, setting expectations of project, incubation working group, board and broader community (including potential adopters) appropriately.
 
Incubation Working Group (IWG) - The Incubation Working Group (IWG) oversees the incubation process. The IWG is also responsible for periodic review of unsponsored Contributions. The Incubation Working Group consists of volunteers solicited from the Apereo community and approved by the Apereo Board. As with all groups operating under the auspices of Apereo, the Working Group is bound by Apereo by-laws. The Executive Director is an ex-officio, non-voting member of the group. Members of the IWG are expected to serve as mentors once they achieve the needed qualification of at least two years experience of participation in a software community. The IWG will play a central formative and coordinating role in the development of the Apereo Mentor Program. The IWG is responsible for:

Assisting proposed projects in conforming to Apereo guidelines;

  • Assigning a Project Mentor, a member of the Apereo community assigned to help the Incubated Project reach acceptance;

  • Evaluating progress of the Incubated Project on a regular quarterly basis and recommending graduation to an endorsed project, continued support, or retirement, according to established criteria

Project Lead - Individual making to incubation request.  The IWG will work with this person to complete the tasks to exit incubation and become an Endorsed Project. 
 
Mentor - The Mentor is a particular person assigned by the Incubation Working Group to guide a candidate project through incubation. Mentors will normally have at least two years experience of participation in an endorsed software community. This need not necessarily be an Apereo endorsed community. Mentors participate in the Apereo Mentor Program. This program provides opportunities for training, monthly discussion of common issues and other opportunities to develop the skills required of mentors.
 
Board - The Apereo Board provides strategic leadership for Apereo, and is elected by representatives of Apereo member organisations. It oversees and supports the IWG and the process they execute. The board provides strategic guidance for the IWG, and is the overall custodian of foundation resources. The IWG provides additional strands of community and technical input for the board, particularly around the health of incubating and endorsed projects. Alignment and consensus between these two groups is an important component of the incubation process. Regular public and bi-directional communication is essential to creating and maintaining this consensus.
 
Unsponsored Contribution - In some cases, software may be contributed without being made by a sponsoring project. Such a contribution may exist indefinitely without becoming an Endorsed Project. Periodic review of unsponsored contributions is the responsibility of the Incubation WG.  Software related to an Endorsed Project also may end up in as an Unsponsored Contribution when the Project governance structure decides it is not a viable component.

Appendix 2: Software Community Health Template

[This information will form the core of the Apereo annual report for 2019 and is based on the work of the Software Community Health Strategic Working Group. It will also form the core description of your software community on the re-worked Apereo web site. Don’t worry too much about style, that will be homogenised to an extent centrally. The working group will update this material on a six monthly basis.]

[Software Community Name]

Status: Incubating/Graduated Incubation

[Please delete as applicable. If your software community is pre-Apereo and was an approved community of either Jasig or Sakai, indicate “Graduated”]

Background and Objectives

[Please provide a paragraph or two on the general background, objectives and scope of your software community. This does not need a high level of detail but should be enough to convince an interested reader to follow links to further detail. Think of it as a pitch. Feel free to replicate existing web content for the description if you have it.]

Technology/ies

[Please briefly outline the technology/ies used by your software community.]

Statistics
Date of First Release Date of Last Release Number of Releases
     

 

Commits in 2018 Commits in 2019 Frequency of Commits
    [Daily, weekly, or monthly]

 

Contributions in 2018 Contributions in 2019
   

 

Number of sites in use (estimated)                                                       

 

Context

[Provide any further information you feel appropriate to contextualise the statistics you have provided. For example – the pattern of contribution and commits for software designed to be centrally cloud hosted would be very different to software hosted in-house]

2018 [Software Community] Highlights

[Please provide a brief description of progress and issues resolved]

 

2019 [Software Community] Highlights

[Please provide a brief description of progress and issues resolved]

 

Future Plans

[Please provide a brief description of future priorities and plans]

 

List and link to repositories and downloads

 

List Commercial Support

[To be completed centrally from list of commercial affiliates]