1. Need to strive for all dimensions of digital sovereignty for platforms!

1. Data sovereignty: Control over sharing data and metadata, GDPR compliance
2. Provider switching capability: Multiple providers offering the same open interfaces and fulfilling the same strong technical standards make switching easy for users
3. Technical sovereignty: Openly developed open source code (four opens) for the complete infrastructure stack
4. Skills and Transparency: Operational experience is transparently shared, enabling medium-sized orgs to successfully operate (and federate) their own infra

2. Data sovereignty is not to be mistaken for digital sovereignty

1. Plenty of proprietary offerings disguise their offering as being digital sovereign, while at best offering data sovereignty only. The term sovereign-washing comes to mind, since fulfilling the requirements of GDPR and alike is part of digital sovereignty, one of its dimensions, but not its only.
2. A platform not built upon open standards, without open APIs will neither offer provider switching capabilities nor allow federation nor offer the option of cloud repatriation but instead a full reliance on continuity by the single provider.
3. Proprietary Cloud platforms operated by on-prem or data centers not belonging to the provider or vendor, still rely on updates and continuity by the single vendor.

3. Creating one European hyperscaler ("cloud airbus") is not a desirable goal!

1. The dependencies would be just as strong as they are on the existing (US/CN) hyperscalers, we'd have a monopoly
2. While legal leverage might be a bit better, and a bit more value creation happens inside Europe, a monopoly won't likely deliver the quality, the innovation and cost efficiency that is desirable
3. Multiple European providers competing with each other to become THE European hyperscaler contradicts the idea of collaboration within Europe by which leverage on value-creation is highly increased.

4. Europe's industry is strong and resilient because of its highly distributed and specialized nature (with lots of small- and medium-sized businesses), we need to structure German/EuroStack along this strength!

1. For platform markets, this model however is at a disadvantage due to network effects, favoring "the-winner-takes-it-all" outcomes.
2. The disadvantage can be overcome by collaboration on standardization, creating a network of highly interoperable clouds.
   • This needs meaningful open standards and strong and highly skilled standards management in the joint interop standardization group.
3. Open Source allows to collaborate on sharing implementation efforts and innovation as well.
4. Open Operations allows to collaborate on building operational skills (helping to overcome shortage of skilled personnel).

5. We don't need to wait for yet another initiative to be completed, we can start today with what we have!

• The majority of Open Source cloud providers are using highly similar technology.
• Every relevant cloud provider offers a managed Kubernetes platform.
• Yet each and every cloud provider differs in their APIs and interfaces to a degree that standard and coherent expectation management is hard.
• The Sovereign Cloud Stack (SCS) standards ensure interoperability between them, thus delivering on the provider switching and federation capabilities promise.
• For green fields, the SCS project offers a complete, openly-developed open source reference implementation that's in productive use by more than half a dozen operators, public, community and private clouds. Standards are met by providers using most of it as well as by providers not (or only scarcely) using it.
• IPCEI-CIS, 8ra, NeoNephos ... initiatives may well connect and build upon SCS standards and SCS technologies to deliver the next generation in the future.
• Likewise, openDesk integrates existing, proven open source solutions into a comprehensive workplace solution. While it needs further growth, it is already a proven and capable solution.
• SCS and openDesk work well together and are a good starting point for the core of a successful EuroStack / GermanStack.
• ZenDiS has done an enormous job getting openCode off the ground - the ecosystem needs to wake up and follow with greater adoption now.
• Other OSS building blocks (such as e.g. from the international GovStack) initiative) can contribute to this as well.

6. Not every company that talks about their support of digital sovereignty may have the best interests of European citizens and businesses in mind.

• Some do not even have a comprehensive understanding of the term digital sovereignty.
• With digital sovereignty becoming a hot topic, there is a lot of marketing happening to attract big business; we observe a lot of noise and sovereign-washing.
• There are companies and non-profit organizations that have been working on and consistently advocated for solutions that really empower their users to become less dependent on single vendors. We should trust these over the fresh "supporters" of digital sovereignty (even if the latter are larger) and put them in the center of a cloud network.

7. Aligning regulation, project funding and procurement is needed for impact!

• Public money, public code: Software that is developed with public money should be Open Source, so it can be trusted, reused, adapted, maintained, resulting in higher cost-efficiency and more control.
• Regulation is only as effective as compliant solutions are available; project funding may help to create compliant solutions. This has no negative impact on competition if the solutions are open.
• While procurement must put the technical needs at the first place, the findings of funded projects and the availability of solutions emerging from them must not be disregarded. Some non-functional requirements around security or sovereignty also may not be negotiable.
• The procurement power of the public sector is significant and should contribute to the economic viability of sovereign solutions and thus ensure their sustainable availability.

8. Technology innovation is iterative and needs intense and open exchange between regulation & standardization, technology development, validation, operation!

• No waterfall design approach but cross-functional teams with a pronounced learning culture are needed. Innovation is not possible if you can not tolerate errors and failures. Innovation requires risk-taking and exploring multiple avenues.
• Design and architecture should be inspired by experiments with minimal viable products.