0 Purpose of this Document

The purpose of this document is to provide detailed information about the open-source projects and ALASCA, including:

1. An introduction on the idea behind accepting new projects into ALASCA

2. An overview of the two project stages: Snowflake and Glacier

3. General requirements for open-source projects

4. Stage-specific requirements

5. Tasks, rights, and responsibilities after moving to ALASCA

6. Application process for new projects

If any questions arise, don’t hesitate to reach out to [contact].

1 Introduction

ALASCA is dedicated to advancing digital sovereignty through the development of open-source technologies related to cloud infrastructures. The association is open to accepting new projects that align with its mission and fall within the scope of cloud infrastructures.

While ALASCA primarily focuses on open-source projects, under specific circumstances, projects with open-core models may also be considered. Closed-source projects interested in transitioning to an open-source model are welcome to apply, and ALASCA can provide support during this process.

All interested projects must follow the application procedure.

2 Project Stages

ALASCA’s primary focus is on ensuring that projects are continuously developed and improved for successful, practical use. Projects are categorized into one of two stages based on their level of maturity:

• Snowflake Projects: Early-stage projects in the initial phases of development
• Glacier Projects: More mature projects with substantial codebases, productive usage, and well-developed aspects beyond just the code (e.g. documentation)

The stage for each project is determined by the Technical Steering Committee during the application process. Projects that begin at the Snowflake level may be upgraded to Glacier status once the requirements for this stage are fulfilled.

3 Requirements for Project Stages

All projects within ALASCA, regardless of their stage, must meet certain general requirements. Additionally, there are stage-specific requirements that vary between the Snowflake and Glacier stages.

3.1 General Requirements

1. License Type: All projects must operate under the Apache 2.0 license. Exceptions must be approved by the Technical Steering Committee (TSC).
2. Number of Committers: Projects should be actively maintained by at least two contributors. Single-person projects may request an exception from the TSC, if applicable.
3. Project Size: Projects managed by organizations, such as companies, must involve multiple parties (i.e., no single-vendor projects).
4. Mission Fit: Projects should contribute to ALASCA’s mission of fostering digital sovereignty by developing technologies that support cloud infrastructure.

3.2 Stage-Specific Requirements

Projects must meet certain criteria within specific categories based on their stage:

1. Roadmap

2. Documentation

3. Release Management

4. Contributing Guide

5. Quality Assurance Concept

6. Project Governance

It is important to note that projects in the Snowflake-stage should actively work towards achieving Glacier status by meeting the stage’s requirements.

Projects in the Glacier stage are expected to continue evolving within these categories towards the respective desired state (and maintaining it), rather than merely meeting the minimal requirements.

The TSC is available to provide support if challenges arise.

3.2.1 Roadmap

3.2.1.1 General Expectations

Projects are expected to maintain a clear roadmap. This is crucial not only for the success of the project itself, but also for the TSC to monitor progress. A roadmap helps the TSC stay informed about the project’s direction and enables timely intervention if the project deviates significantly from its planned course.

3.2.1.2 Requirements for Project Stages

Stage 1 - Snowflake:

• Snowflake-projects are not required to have a fully developed roadmap yet
• However, they should however work towards meeting the requirements for the Glacier-stage.

Stage 2 - Glacier:

• Glacier projects must have at least a list of prioritized goals, though specific deadlines are not mandatory.

Desired State:

• Comprehensive roadmap
  • Develop a list of objectives for each release and review the outcomes after each release.
  • The roadmap may consist of a set of epics, user stories, or blocks of work, each with target dates for completion.

3.2.2 Documentation

3.2.2.1 General Expectations

Requirements concerning the project’s documentation lean on the Diataxis-framework. Diátaxis identifies four modes of documentation - tutorials, how-to guides, technical reference and explanation. It derives its structure from the relationship between them.

In Diátaxis, each of these modes (or types) corresponds to a different user need. Each fulfills a different purpose and requires a different approach to its creation:

• Tutorials are lessons that take the reader by the hand through a series of steps to complete a project of some kind. Tutorials are learning-oriented.
• How-to guides are directions that take the reader through the steps required to solve a real-world problem. How-to guides are goal-oriented.
• Reference guides are technical descriptions of the machinery and how to operate it. Reference material is information-oriented.
• Explanation is discussion that clarifies and illuminates a particular topic. Explanation is understanding-oriented.

3.2.2.2 Requirements for Project Stages

Stage 1 - Snowflake:

• There are no strict documentation requirements for Snowflake projects.
• However, a basic level of documentation should be in place, as creating it from scratch at a later stage can be challenging.
• Snowflake projects are expected to work toward meeting the documentation requirements for the Glacier stage, using the Diátaxis Framework as a guideline.

Stage 2 - Glacier:

• Certain aspects of the Diátaxis Framework must be addressed at the Glacier stage.
  • A Reference Guide is required, with approximately 80% of the content already completed.

Desired State:

• All aspects of the Diátaxis Framework are fully covered
• Should also cater to different target groups:
  • At least two personas: Developer and Operator
  • A third category, such as End-User, may also be required.

3.2.3 Release Management

3.3.1.1 General Expectations

An optimal release management plan should define the following categories:

1. Requesting

• Ticketing System: A publicly accessible ticketing system must be available for users to report bugs and request features.
• Communication: Defined channels for communication must be established.

2. Planning: - Release and Versioning Policy: Define the scope of the release (content- or time-based); versioning should follow a clear system, such as Semantic Versioning (Semver). - Deprecation Policy: Establish guidelines for handling deprecations, including the duration of support for deprecated items. - Hotfix Policy: Define how hotfixes for older versions are integrated.

3. Developing:

• Code Reviews: Code must be reviewed by someone other than the developer before approval. Reviews should check for clear, syntactically correct code and ensure necessary documentation updates are made. This can be implemented through checklists or tools (e.g., CI pipelines).
• Version Management: Use a version control system, such as Git. While not directly part of Release Management, this should be considered.

4. Testing: - Functional and Non-Functional Tests: Appropriate tests must be defined and implemented automatically. These may include: - Integration tests (e.g., with OpenStack or Tempest) - Regression tests - Functional tests - Unit tests - Performance tests - Smoke tests Skipping tests is not permitted, and test results should be made visible.

5. Preparing: - Documentation: Documentation should be current, comprehensive, and tailored to the target audience (refer to the “Documentation” requirement). - Changelog: A changelog or release notes should provide an overview of changes in each version. An example format is keepachangelog.

6. Deploying/Releasing: - Define how releases will be made available.

3.3.1.2 Requirements for Project Stages

Stage 1 - Snowflake: - There are no specific release management requirements for Snowflake projects. - However, projects are expected to work toward meeting the release management criteria for the Glacier stage.

Stage 2 - Glacier: - A minimum of one release per year, accompanied by release notes. - Release notes should be maintained continuously, not only after a release is finalized. - Certain key areas of the optimal release plan should be defined.

Desired State: - Full release plan including definition and implementation of all six aspects

3.2.4 Contributing Guide

3.2.4.1 General Expectations

The contributing guide should help (potential) contributors understand the steps involved in contributing code, reporting issues, and suggesting features. Open-source projects are expected to provide a comprehensive guide that covers these aspects.

3.2.4.2 Requirements for Project Stages

Stage 1 - Snowflake: - There are no specific requirements for Snowflake-projects concerning the Contributing Guide - Snowflake-projects are however encouraged to prioritize providing information to the following aspects: - Instructions on how to set up the development environment - Information on the minimum hardware and software requirements for running and contributing to the project - Basic contribution guidelines - How to submit code changes or bug reports - How to create a pull request - General expectations for small contributions (e.g., bug fixes) - After covering these basics, projects are expected to work towards fulfilling the Glacier requirements.

Stage 2 - Glacier: - The contributing guide for Glacier-projects should be more comprehensive, addressing not only how to contribute but also the expected quality and standards for contributions: - Advanced contribution workflow for issues and feature requests incl. basic templates - Code style - E.g., naming conventions, file structure, code formatting - Examples of unacceptable contributions - Guidelines for what to expect of the review process

Desired State: - Full contributing guide (to be defined).

3.2.5 Quality Assurance Concept

3.2.5.1 General Expectations

Quality assurance (QA) is a central element to ensure the security, stability, and long-term sustainability of open-source projects and helps stakeholders to rely on a predictable level of quality in order to integrate, maintain, and trust the technology.

QA must therefore address:

• correctness of the codebase,
• security and resilience against vulnerabilities,
• and the traceability of dependencies.

3.3.5.2 Requirements for Project Stages

Stage 1 - Snowflake:

• A basic level of QA is required for Snowflake-projects.
  • Testing: At minimum, basic unit tests and code style checks (depending on language) must be present.
  • Test Coverage: While full coverage is not expected, projects must begin to measure and report coverage.
  • Incident Management: The project must designate a responsible contact for handling security-relevant bugs. It must be clear how incidents can be reported.
  • Resilience: A minimum level of project activity is expected, demonstrated by regular commits and at least a small group of active contributors.
• After covering these basics, projects are expected to work towards fulfilling the Glacier requirements.

3.2.5.3 Stage 2 - Glacier:

• Glacier projects must demonstrate a comprehensive QA framework:
  • CI/CD Pipeline: Automated testing is required. This includes running unit and integration tests on every merge/commit, with visible status reporting.
  • Test Coverage: A significant portion of the codebase must be covered by automated tests. While 100% coverage is not required, gaps must be documented and justified.
  • Incident Management: A formalized process must exist for handling security incidents. This includes:
    • a publicly communicated point of contact (may be a private issue tracker or mailing list),
    • clear internal responsibility for timely handling of vulnerabilities,
    • alignment with legal requirements (e.g., Cyber Resilience Act).
• Resilience: A sustained contributor base is required, with multiple maintainers actively engaged to avoid single points of failure.

3.2.5.4 Desired State: - The desired state for QA aims at the following quality practices: - Full SBOM (Software Bill of Materials): Projects maintain an automated, regularly updated SBOM that lists all dependencies. This enables fast and transparent responses to upstream security issues. - Advanced CI/CD: Pipelines include not only testing but also automated security scanning, dependency checking, and release validation. - Comprehensive Testing: All critical components of the project are covered by automated tests, with regular audits to improve coverage. - Mature Resilience Model: The project demonstrates sustainable contributor activity, a bus factor >1, and community mechanisms to onboard new maintainers.

3.2.6 Project Governance

3.2.6.1 General Expectations

Clear and well-structured project governance is essential for the successful management and growth of our open-source projects. It ensures that all participants understand their roles, responsibilities, and rights within the project, which fosters efficient collaboration. A well-defined governance structure also benefits newcomers by providing clarity on how to get involved and whom to contact.

Projects are expected to define the different roles within their community, as for example users, contributors, maintainers, and leaders, as well as guidelines on how to take on a certain role. This information should be easily accessible for community members as well as newcomers.

3.2.6.2 Requirements for Project Stages

Stage 1 - Snowflake:

• There are no requirements regarding project governance for Snowflake projects.
• However, there should be designated contact persons within the project to ensure that questions, decisions, and responsibilities can be clearly addressed.

Stage 2 - Glacier:

• Should specify and then provide info – especially for newcomers - on
  • which roles exist
  • which responsibilities the roles have
  • how to obtain a role

Desired State: - Projects should have a profound overview of the project’s governance including a voluntary “who is who” or similar strategies to make the project more human and personal.

3.3 Tasks, Rights, and Responsibilities

Once an open-source project moves to ALASCA, certain tasks, rights, and responsibilities remain with the project, while other areas will be managed by ALASCA.

3.3.1 Ownership of the Project

After the transition, the project is officially part of ALASCA, and all parties involved must communicate it as such.

For example, if two companies built an open-source project and then moved it to ALASCA:

• They can no longer refer to the project as "their" project, but must refer to it as an ALASCA project.
• They may continue to communicate their past and ongoing contributions, and can still identify themselves as the founders of the project.
• The original project owners will retain their roles after the transition, as will other project members, such as maintainers.
• Existing trademarks do not need to be transferred to ALASCA, but an agreement for their free use by ALASCA should be arranged.

3.3.2 Direction of the Project

The project remains responsible for setting its overall direction, such as its roadmap. However, regular communication with the TSC is expected, as the TSC ensures the project adheres to the requirements of its current stage.

The TSC may also make development suggestions (e.g., to address gaps in the code). While projects are encouraged to discuss these suggestions, they are not required to implement them.

3.3.3 Internal Organization

ALASCA does not impose requirements on the internal organization of the project (e.g., meetings, communication). However, project activities should remain transparent to the community, such as by sharing meeting notes.

The project is also responsible for resolving any conflicts or Code of Conduct violations. ALASCA can provide support and guidance if needed.

3.3.4 Marketing and Branding

If a project does not already have a logo or design, ALASCA will work with the project to create a corporate identity, including a logo, name, and project colors. The design will be inspired by the animal kingdom in colder regions. Project leaders and the community will be involved in every step to ensure their input is considered. ALASCA may also assist with building a project website if necessary.

For projects that already have a logo or design, a discussion about whether to keep the existing identity or create a new ALASCA-aligned identity is encouraged.

In terms of visibility, ALASCA is committed to supporting projects. In addition to being listed on the ALASCA website, projects can benefit from social media promotion (e.g., LinkedIn posts for major milestones) and participation in both internal and external events.

ALASCA does not provide a fixed marketing budget, but special marketing requests can be discussed on a case-by-case basis.

3.4 Application Process

To apply for inclusion in ALASCA, projects should follow these steps:

1. Submit the Application Form: Complete the form, providing detailed information about the project, including its current status and goals.

2. TSC Review and Vote: The Technical Steering Committee (TSC) will review the application, discuss the project’s alignment with ALASCA’s mission as well as its developments, and hold a vote to decide on the application. Note: The board reserves the right to exercise veto power.

3. Decision Notification: The project will receive notification of the TSC’s decision by the ALASCA's board.

4. Onboarding Call: If accepted, a joint onboarding call will be scheduled to discuss next steps and the process of integrating the project into ALASCA.