Skip to content

How and why to apply - onboarding projects

It is really great that you're thinking about joining ALASCA! We try to make your experience as easy as possible.

Why you should move - your benefits

Strategic advantages

  • vendor neutral governance for your project
  • strenghtens trust with partners, clients and contributors
  • multi vendor contribution and joint decisions
  • longlasting project stability through vendor neutrality
  • support in building of your project’s community
  • increased visibility
  • a strong community beyond your project’s community
  • support with the organisation of project hackathons and other events
  • a space and community to build connections and share knowledge through hosting events like the ALASCA Summit

Advantages in Marketing and Communication

  • full branding, including logo, name and CI
  • presence on ALASCA Website
  • stand alone project website, if wished for
  • support in target group oriented messaging
  • continuity in messaging and branding
  • association with an established ecosystem
  • strong brand recognisability
  • communication via foundation’s channels like LinkedIn, Website, Newsletter, Mastodon or Matrix etc.
  • professional image through branding but also through the affiliation with a known Open-Source foundation
  • professional presence at events

Technical Advantages

  • provided infrastructure, e.g. GitLab Ultimate (through Gitlab for Open Source), Mailinglisten, Hedgedocs , CI/CD-Systems
  • compute for your project on SCS certified infrastructure
  • established Technical Steering Committee & FOCIS project
    • provide support with documentation, governance, network etc.
  • Connection and exchange with the other projects
    • Cross-project development
    • Best practices
  • Support for the technical “roadmap” for your project
    • definition of graduate maturity levels (Snowflake, Glacier)
    • assists with the strategic and orderly further development of the project
    • shows a professional image to the outside

How you do it - the application process

Please answer all questions from the Onboarding Questions section and provide them either as a pull request to this repository or as part of an email to the ALASCA association. Afterwards the TSC will discuss your application and hold a vote to decide. The board will then inform you about the decision. If accepted, we will schedule an onboarding call, to help you to get started as an ALASCA project. A detailed overview of the full process can be found in the following diagram:

Onboarding Questions

Do you have a project, that also supports digital sovereignty in cloud infrastructures? Do you want to develop open source? Why do you want to open source you project within the ALASCA association?

Please answer the following questions, if you and your project want to join ALASCA:

  1. What is the purpose of your project? What is it about?
  2. How exactly does your project supports digital sovereignty in cloud infrastructures?
  3. If there is already a project doing something similar in the ALASCA context: How is your project different?
  4. If your project is already open source, please provide a link to the source code.
  5. All projects should operate under OSS license (e.g. Apache 2.0). What license do you currently use? (The TSC can also help you to change your license to OSS.)
  6. How many contributors does your project have?
  7. How many companies are involved in this project?
  8. What do you expect from moving you project to ALASCA?
  9. Who can we contact, if we have further questions?

Further details, we would like to know about your project (answering "no" will not be a disadvantage):

  1. Do you have a quickstart guide to get a first impression of your software?
  2. What kind of documentation do you have yet?
  3. What further topics do you want to address in you project? Is there a roadmap?
  4. Do you have a release plan / release management in place yet?
  5. How do you integrate new contributors? Is there maybe a guide for new contributors?
  6. How do people report bugs to you?
  7. How does your project governance currently look like? Are there maybe different roles for contributors (e.g. one that can merge code into the project and another that only can suggest code)?