Germany Stack - Cloudogus statement on the second consultation round

As a medium-sized company in the digital industry that offers its products as open source software and has also been working for the public sector for almost 10 years, we at Cloudogu GmbH are pleased to provide feedback in the second consultation round on the Germany Stack.

Johannes Schnatterer

Field CTO

We also shared this post via the official OpenCode channel as part of the participation process for the Germany Stack.

Summary

We see it as a positive sign that feedback from the first consultation has already influenced the strategic direction, portfolio, and criteria of the Germany Stack. We are particularly pleased to note that parts of our demands from the first consultation (see #428) are reflected in the current draft:

Open source, both in preferred awarding and in in-house developments within the framework of the D-Stack
Dynamic procurement, naming of initial existing marketplaces, and reuse of DVC offerings
Naming of existing technologies such as SCS and KIPITZ

We see these as steps in the right direction and would like to see further refinement:

Strategy: Specification – is D-Stack binding or not?
Portfolio: Find other successful systems through inventory and promote reuse, for example, OpenDesk, SWEC, etc.
Procurement: Create conditions that are favorable to small and medium-sized enterprises
Other activities: Establish or delineate more connections, for example, to GovStack and marketplaces such as FIT-Store, EfA-Marktplatz, and Cloud Service Portal, GovTech's platform for Germany.
Criteria: Specify by naming the contents of the stages of the first draft
Digital sovereignty criterion: Define the term open source/free software, distinguish it from openwashing, source available, and open core.
Specify technology fields and establish a process for regular updates.
Tech stack map: Publish as open source. Maintain overview, for example through tech radars, golden paths, alternatives.
Build trust by listing sources, facts, and, above all, references.

In the following, we will look at the changes since the first consultation round and address the specific questions raised in the second consultation round.

Overall picture

This section looks at the “Overall picture” page (‘Contexts’ in the side menu) with the exception of the “Technology fields and standards” section. Due to its technical depth, this is covered in a separate section.

We perceive a significant sharpening of the existing areas such as motivation, contexts, and portfolio. In particular, the technology fields clarify many points such as standards and protocols without bloating the map.

Strategy

The new section on strategy creates a broader political basis, primarily through the evidence provided. It goes far beyond the coalition agreement, which has been the sole reference point to date. By giving priority to open source solutions or solutions from European sovereign providers, it meets a demand that is omnipresent in the public debate on digital sovereignty.

The additional clarification that “necessary proprietary components of solutions” will be developed as open source complies with the often-demanded principle of “public money, public code.” However, this must also be delivered, because so far only the d-stack-home repository is accessible; the repository of the map is not (yet) available. As in our statement on the first consultation procedure #428, we call for a transparent admission process by publishing the map as open source. This would allow for a transparent discussion about the inclusion of further technologies. In addition, this process would enable providers and users to maintain the entries and view a history.

The strategy section remains unclear: Should the Germany Stack now be binding or not? What exactly is meant by “binding and optional use”?

Pillars are set based on “experience from previous implementations and existing implementation conditions.” It would be helpful to specify which implementations and implementation conditions are meant here.

Connection to other activities

The section “Connection to other activities,” which already existed before the first consultation, now offers more clarity. The addition of the federal modernization agenda expands the potential of the D-Stack at the state level. The clarification of the relationship between the D-Stack and the German Administration Cloud (DVC) is welcome, and it makes sense to reuse the preliminary work.

It is striking that GovStack is no longer mentioned in the current version. It would be interesting to know why. In general, it can also be helpful to mention activities that are not related so that these discussions do not keep coming up again and again.

Portfolio

The portfolio has been structured around the three elements mentioned above: “platform core,” “technology-agnostic platforms,” and “managed services.” The mention of specific examples such as EUDI Wallet, FIT-Connect, KIPITZ, Marktplatz Deutschland Digital, DVC Portal, and OpenCode creates a practical relevance. We believe it makes sense to continue taking stock of existing successful systems in the public sector, focusing on already established, sovereign technologies. Further examples are OpenDesk from ZenDis and SWEC from ITZBund. These are also subject-agnostic platforms, but in a specific domain (digital workplace and software development/project management). There are undoubtedly many other products or standards here that the D-Stack could help to reuse. We see this as one of the most important and lowest-hanging tasks of the D-Stack.

Taking up the idea of creating a dynamic procurement system can speed up the awarding of contracts, simplify access for startups and SMEs, and promote innovation. Mentioning existing marketplaces such as Marktplatz Deutschland Digital and DVC Portal creates connections. However, it is unclear how this is to be understood exactly – will these become part of the D-Stack? What about other marketplaces such as FIT-Store, EfA-Marktplatz, Cloud Service Portal, GovTechs Plattform Deutschland – will there be consolidation here? In the area of procurement, we see a particular opportunity to drive innovation, for example through an SME quota or SME-friendly participation conditions. Small businesses in particular are often lightweight and innovative, but are disadvantaged by the usual procurement process. They do not have the human resources, expertise, legal support, or references to win large framework contracts through tenders. Badges, as used by some large retail platforms, can be another helpful tool, as they visualize when products are offered or supported by SMEs.

Criteria and maturity level

Before delving deeper into the technology in the section “Technology fields and standards,” the following section looks at the “Criteria and maturity level” page (“Criteria in the stack” in the side menu).

The significant simplification of the criteria since the first consultation helps in practice, especially for those who are required to comply with them. In some places, however, the simplification comes at the expense of clarity. Some topics have become less specific, such as market relevance, trustworthiness, sustainability, and digital sovereignty. Here, the contents of the levels would serve as a concretization – if only to understand which aspects are taken into account in this criterion.

In the case of digital sovereignty, the interchangeability between operators and providers as a minimum requirement, as well as at least the mention of open source, makes sense. We consider the criteria of provider influence and design capability (product participation), which were still listed under the levels in the first draft, to be particularly important, especially in the public sector. Regardless of the levels in the first draft, these terms should be mentioned again as a clarification or guiding questions for the criterion of digital sovereignty. Furthermore, it would be useful to define the term open source and/or free software (e.g., through an OSI-compatible license) and to delimit or explicitly mention the framework conditions. Here we see the distinction from openwashing, source available, and open core. In addition, rights holders/code owners (company vs. NPO/consortium/association/foundation) and the applicable legal jurisdiction are relevant. Example: There are more reliable alternatives to the only source code management in the current tech stack GitLab (American company with an open core model), such as Forgejo (open source, further development by the German association Codeberg) or SCM-Manager (open source, further development and support by Cloudogu, an SME from Germany).

In terms of interoperability, openness is mentioned as a “welcome factor.” So is this not a minimum requirement?

In terms of future viability, the minimum requirement is that solutions are continuously updated. This should be specified in concrete terms so that it can be measured numerically, for example, “at least every n weeks in the last m months or since the start of the project.”

Technology fields and standards

This section refers to the page “Overall picture” (‘Contexts’ in the side menu), section “Technology fields and standards,” and thus specifically to the second question of the consultation process: “Are the prioritized technology fields underpinned by the relevant technologies and standards for the Germany Stack?”

We can contribute specific details on some technology fields based on our experience in developing and operating cloud-native and AI applications.

Agentic and generative AI: This technology field in particular shows how important it is to plan a process for updating the D-Stack from the outset. The field is still new and highly dynamic. For example, developments in recent weeks suggest that the spread of the Model Context Protocol (MCP), which is also only a year old, could decline again (example). This is comparable to how the hype surrounding MCP a year ago caused the hype surrounding Retrieval-Augmented Generation (RAG) to level off. This development will not end here. In this respect, quarterly updates of the D-Stack technology fields would be a good minimum requirement.

DevSecOps and APIs: SBOM itself is not a standard, but a concept. Common standards are listed by CISA, for example: SPDX, CycloneDX, and VEX. In addition to Git and principles such as CI/CD pipelines and IaC, the concept of GitOps has established itself as cloud-native continuous delivery. The three points on “mechanisms” are very general. These should be specified in more detail. For “monitoring, logging, and observability,” our suggestion is “observability (monitoring, logging, tracing, and profiling),” as observability is commonly understood as an umbrella term for the four pillars mentioned. Specific common standards are Prometheus (OpenMetrics) and OpenTelemetry. For “mechanisms for package management and distribution,” OCI (Open Container Initiative) is the most common standard. It has evolved from a container image to a generic standard through which SBOMs, signatures, Helm charts, WebAssembly modules, machine learning models, etc. are also distributed.

Managed services and cloud: In the cloud, the concepts of an exit strategy and the associated possibility of cloud switching as an implementation of the minimum requirement of interchangeability (see digital sovereignty) are worth adding. Cloud switching is also required by the EU's Data Act (see blog post by Cloudogu). The D-Stack should not lag behind here.

IT security: When it comes to security, it is helpful to specify the relationship between the aforementioned BSI IT-Grundschutz / C5 and the common topics NIS2 / ISO 27001. Does the D-Stack consider ISO 27001 and/or NIS2 compliance to be sufficient? When specifying cryptographic algorithms, either more precise specifications (e.g., key lengths) are necessary and/or a time limit is advisable. According to the BSI, for example, the RSA mentioned in the D-Stack is only permissible with longer key lengths. Just recently, the BSI published general migration deadlines for the discontinuation of classic asymmetric methods with regard to post-quantum cryptography.

Tech stack map

We see no difference from the first consultation in terms of the tech stack map. We still believe that finding the right balance between selection and overview is crucial for the usability and success of the D-Stack. By creating the technology fields and standards documented outside the map, the standards can be removed from the map to gain an overview. This leaves us with specific technologies. The fact that these alone can be more than enough is demonstrated by the huge CNCF landscape, which serves as the technological basis for the representation of the tech stack. At tech conferences, it regularly appears in sarcastic memes to visualize the agony of choice when selecting the right cloud-native technologies. With its domain-specific criteria, the D-Stack map has the potential to be more useful than the CNCF landscape. Methods familiar from tech radars can be supplemented here with more specific details. Perhaps a “golden path” approach can be implemented that highlights the most common solutions and possible integrations for common use cases.

The map should also list facts and sources. More sophisticated alternatives should also be displayed directly.

References can be a confidence-building measure for technologies: Where in Germany, Europe, in the public sector, at which authorities is a product used, and how many users use it?