My response to European call for feedback on open source - Lemmy.World
So, the response I wrote to the European Open Digital Ecosystems call for
evidence turned out to be about five times longer than the character limit for
the feedback prompt. However, there was also an option to submit .odt and .pdf
files, so I was able to submit my response in full. The response took weeks to
write, with many of the points thoroughly discussed and explored before being
put into writing. I decided to post it here as well because it is an important
topic to discuss. As with any exploration of a topic, some nuance is inevitably
lost, despite my efforts to be precise while trying to encompass the entire
digital chain. I also had help from a co-writer to finish the response because I
got the flu with three days left before the deadline and was basically bedridden
until today. Also, if you haven’t shared your thoughts yet, you still have until
midnight today.
---------------------------------------------------------------------------------------------
There are great obstacles to widespread adoption of open source and its
subsequent thriving in the EU and its market. Further details on these will be
explained later in the key objectives section. But before we look at what we
could or should do, let’s briefly look at the consumer’s place and options in a
European open digital ecosystem. Because, in a sense, open source is already
thriving in the EU, as well as the rest of the world. Every server, router, and
cloud service does either in full, or in major part, run on open source
software, protocols, and/or code. Because all the major players have realized
that they all gain from sharing and contributing to it. Their finished product
isn’t necessarily open source, but its foundation is built, or rests, on it.
With the end consumer, the choices and options are often only surface level, and
I’m using consumer here because not all who interact with software or services
are “users”. We, the consumers, are often forced to interact with applications,
services, and systems out of necessity rather than choice. Participation in
digital society today is, in practice, compulsory rather than optional. This
will, if it hasn’t already, lead to a process in which an individual must
sequentially accept non-negotiable contractual constraints imposed by multiple
independent corporations, often across jurisdictions. In order to perform a
mandatory (or because the alternative would effectively “soft-lock” the
individual out of the system) civic or economic function, each acceptance
irreversibly alters the individual’s legal rights in practice. This creates what
can be described as compelled rights violating dependency chain. While we have
very strong and clear legislation, such as COUNCIL DIRECTIVE 93/13/EEC 1,
enacted to mitigate these types of EULAs within the EU , the risk is, however,
still present for the individual consumer due to the resource disparity. Having
citizens forced into accepting EULAs with entities outside of the EU in order to
participate in our society, solely because the alternative is non-existent,
creates this rights-violating dependency chain that perpetuates those same
actors monopolistic standing, which in turn, hampers the EU’s security,
sovereignty, resilience, and prosperity, as well as very competent internal
players. If, at any point in the chain, consumers must consent to waiving their
rights to their data and usage analytics in order to participate as functioning
members of society, then such “consent” is fictional. Let me pose this simple
question: What options does the average citizen have to partake in our digital
society, and what services are they required to interact with to remain
functioning members, or to access services to sustain them (medical, civic
duties, social security, taxes, etc.)? Once identified, focus should be placed
on ensuring viable European open source options, not reliant on external (ergo
non-EU) services, are available for EU consumers and citizens. This will require
implementing open source systems throughout our public sectors, all the way down
to the consumer platforms. This would shore up our citizens digital rights,
while ensuring robust cybersecurity audits are possible through all links in the
chain. Re-tooling agencies with open source alternatives is not the largest
hurdle to European digital sovereignty, resilience, and security. It’s a large
hurdle, and challenges awaiting us in this space should not be underestimated.
However, the largest and most important hurdle is consumer adoption of open
source alternatives and EU-based alternatives. Because consumer adoption
requires allure. The alternative supplied can’t just be the better option on
paper. Plenty of failed products throughout history have been the objectively
better options when viewed as a whole, but had too much friction for individual
consumers to adopt. The friction that hinders adoption of an alternative or new
product can be everything from price to ease of use, ecosystem, availability,
compatibility, or even current adoption rate. All of these friction points can
of course be mitigated with various means. But to effectively mitigate these
frictions to adoption, they must be considered early and influence how and where
we put our efforts. For us to be able to take full advantage of a European push
for open source, Directive 2001/29/EC Article 6 needs to be revised, firstly to
ensure digital sovereignty and avoid externally imposed artificial digital
scarcity during European build-up and re-tooling. An advantageous economic
side-effect of this would be domestic actors being able to take advantage of the
new market opportunity created, offering open source EU alternatives for EU
consumers seeking service, support, and software alternatives to devices they
already own from external hardware suppliers. On 2022-05-05, Deutsche Welle
reported that John Deere remotely disabled farm equipment stolen from Ukraine 2.
If the American-owned market leaders in farm equipment in Europe were to be
pressured by their government to disable equipment owned by European farmers, it
would be disastrous for us. It is imperative that we have secured the tools to
counteract such a scenario, to avoid finding us in a situation where we are
forced to reactively scramble to un-brick ~14 Billion EUR worth of combined
harvesters. This is not to mention the massive security risk posed by
extraterritorial legal exposure, namely the CLOUD Act. POINTS FROM FEEDBACK
INITIATIVE Key objectives include: - continuing development and ensuring
appropriate visibility of EU high-quality and secure open-source solutions and
demonstrating their added value; EU should not try to reinvent the wheel. There
are plenty of established open-source projects that could either in full or in
major part be deployed as is. For consumer desktop platforms there are
OS-distributions like Debian and Redhat that are not only the base for many
variations Linux but also very matured and established. On the mobile platform
the options are fewer and unfortunately only two end consumer viable options.
Although Android OpenSource Project - AOSP might at first glance seem like the
best option to fork and create a EU driven version of (there are some forks of
AOSP already trying to realize this). The fact that we are missing a third
viable option for end consumers hampers competition, agility, and consumer
choice. The reasonable choice here would be to support a mobile mainline Linux
distribution such as Sailfish OS, which today struggles with adoption due to
lack of software availability within the ecosystem, and are forced to maintain a
compatibility layer to offer end user functionality. The same would hold true
for public entities, and agency’s within EU, one way to ensure the same
solutions aren’t invented by multiple independent actors, thereby not taking
advantage of the cost savings, faster development, and interoperability that
comes from utilising open-source software ^3, could be by setting up public
sector domain interest groups. These public sector domain groups main purpose
could be to evaluate and formulate requirement assessments and guide development
for their interest group. They could also collaborate with each other on
projects or questions that are relevant for multiple areas. - addressing issues
of deployment, usability, software supply chain security and governance,
maintenance of code and project sustainability to ensure take-up and upscaling;
Complete adoption of open source within the public sector would, de facto,
create favourable conditions to govern and ensure the security of the software
supply chain, while at the same time enabling agile and stable maintenance of
code. This is due to the intrinsic nature of open source; it can be forked,
audited, and contributed to by anyone, thus mitigating the risk of software
being suddenly abandoned or left unsupported because the corporation owning the
software dropping support due to profitability concerns or going out of
business. While in the short term the cost of migration might be higher than the
current rolling costs of maintaining closed-source solutions, in the long term
open-source solutions will be the cost-effective option, especially when these
solutions can be reused and modified freely. Thus, the cost becomes balanced
across the market rather than requiring the same entry toll for every purchaser
of the same closed-source platform. Vendor lock-ins are by far the largest
hurdle for the public sector(goverment agencies) and European corporations.
- supporting emerging open-source business and sustainability models for
open-source companies and foundations, including by developing public-private
partnerships; While this might be outside the scope of this feedback initiative,
we within the EU need to collectively be able to assign certain EU-owned
corporations, producers, manufacturers, or service providers as “strategic” and
prohibit them from being sold off to investors or actors outside of the EU. The
recent loss of Arduino as a strategic European corporation, after the Qualcomm
purchase, is a perfect example of this. This left the EU without a key strategic
internal integrated chip designer and manufacturer. This void needs to be filled
for both civilian and, by extension, military sectors. One way EU could support
open-source businesses could be a EU-driven co-op consisting of public entities
from all member states that acts as a producer and/or customer of open source
software solutions and open source hardware components. This co-op entity could
also act as one part of the strategy to along side public sector domain interest
groups to promote and support emerging businesses, companies, and foundations by
extending grants, offering bounty programs, and purchasing solutions, products,
and services from internal actors. Monopsony is not new to industries or sectors
of our economies that are of strategic value, and while European open source
development does not necessarily have to be fed by one entity, certain projects
could very well require it, and we should not dismiss it as an option for
strategic resources, be they microcontrollers, integrated systems, or management
services. One other benefit of such a co-op would be the negotiating power it
would wield when purchasing contracts for hardware solutions not available
internally on behalf of the member states and their institutions, imposing
EU-aligned values and policies on corporations by acting as the gatekeeper to a
very substantial market. This co-op could also help different public sector
domain interest groups balance costs by identifying aligned needs across the
market or shared code base. Another option for a large-scale solution to to the
public-private partnership development could consist of setting up alternative
revenue models for new and emerging actors. By setting up tiered based on
offerings scale, from simple-to-receive models with short-term proof of work and
deliverables, to harder and more stringent approval procedures for large-scale
projects with long time frames before results can be presented. Examples of this
for simpler, lower-tier projects could be an agency hosting a Codeberg/Git
repository for their custom implementation of Open HRMS 4 and asking for added
functionality from outside contributors with a bounty, granting the bounty to
the author of the pull request that gets committed. The previously mentioned
public sector domain interest groups could also make use of this co-op entity’s
market position to set up contracts, based on their requirement assessments,
with internal actors for projects that require specialist competencies or
integration normally outside of their scope. - promoting best practice and
encouraging the public sector, specialised business sectors and large customers
to contribute to and adopt open source; If the EU mandates that all internal
government systems, as well as public-facing portals and platforms, are open
source, it would create significant opportunities for existing and potential
internal actors to support and maintain these systems. Cross-integration between
sectors would also be greatly simplified, since the code would not be hidden
behind a veil of secrecy and prohibition. One agency’s internal development work
could be applied or modified by another. Both development and code audits would
become essentially collectivized and distributed across all sectors and actors,
lowering costs and simplifying integration and policy alignment, with the added
benefit of creating a more accessible environment for future startups and the
formation of new agencies, foundations, etc. - supporting market integration,
especially with legacy systems and policy alignment With a Fund or Fork
methodology, meaning that the EU could support open-source projects both
internal and external that we deem useful or strategic, with the added benefit
of being able to have influence on these same projects policy alignments, by
financially secure development. While still maintaining control over governance
by having the option to fork, if the project deviates or strays to far from EU
policies and values. Another area were we the EU should put effort is our
digital civilian defence, with alternative network stacks such as reticulum 5 to
ensure functional communication and continued civil operation during emergencies
affecting our infrastructure. 1. What are the strengths and weaknesses of the EU
open-source sector? What are the main barriers that hamper (i) adoption and
maintenance of high-quality and secure open source; Vendor lock-in for the
largest service providers. Both public institutions and private companies are
stuck in ecosystems provided by a few vendors. This relates to both operating
systems for desktops and mobile devices with the accompanying software, but
mainly through the interconnectedness of cloud services provided by these
vendors. Much of the digital infrastructure of European companies is run on
hardware provided by a handful of non EU-providers. These vendors provide whole,
interconnected ecosystems with everything from identity providers, “serverless”,
catalog-services for authorization, virtual networking, storage, security,
secrets management. Although these services are provided by multiple vendors it
is not trivial to move between them, unless the infrastructure was specifically
designed for to be multi cloud. Even then multi-cloud setups mainly focus on
switching between a few of these vendors. Since these vendors provide specific
interfaces, terminology and technology, experience with one vendor does not
directly translate between them, further increasing the risk for vendor lock in.
There are many open source alternatives to the specific services that are
provided by these vendors, however none provide a full, realistic alternative
with the full range of services, technology, and flexibility of these vendors.
While there are mature open source cloud solutions, there needs to be services
that can provide this capability the same type of robustness, support and ease
of use as the non- EU Competitors. Further more EU needs to support projects to
be able to migrate the infrastructure that has already been built for other
cloud vendors. These kinds of projects could focus on converting IaC
(infrastructure as code, for example OpenTofu now that Terraform is no longer
open source) from vendor specific to Open Source Cloud services. While it is
possible to use LLM- based text generators for this, a robust, well tested,
trustworthy solution is needed, as well as a European one. Besides the
conversion of the infrastructure specification, projects that aide in migration
of blob-, and secret-storage. By encouraging these European cloud providers to
use open source cloud infrastructure, it will also ease the adoption of private
cloud and hybrid cloud solutions as these will use the same technology. (ii) and
sustainable contributions to open-source communities? EU could identify critical
or important open source projects and support them by either providing funding
directly, or by committing developer time. 2. What is the added value of open
source for the public and private sectors? Please provide concrete examples,
including the factors (such as cost, risk, lock-in, security, innovation, among
others) that are most important to assess the added value. Having much of EU’s
private and public infrastructure hosted and controlled in potentia by non EU
vendors is that in the event of geopolitical conflict, that infrastructure is
made unavailable, temporarily or permanently, resulting in capital loss, loss of
revenue, and loss of vital services for parts or most of the European market.
While this scenario may seem unlikely due to the negative consequences it would
have for the global market, including the potential adversary, the parable of
the frog and the scorpion comes to mind with increasing frequency since 2016,
and as such it might be advisable to avoid it be possible in the first place.
Encouraging organisations in the European public sector to not only use open
source, but also to actively publish internally developed tools as open source
would provide an opportunity for other organisations, on EU, national, and
regional to benefit from that work and to contribute to it. Many of EU’s
institutions are engaged in similar tasks in their respective domains, and most
of their needs will be identical, while not all. Therefore encouraging these
projects to adopt modular architectures, designed for such cooperation, with for
example a common core functionality and organisational specific modules, would
ease the adoption and development of effective tools, while harnessing the
competence that is found across the continent. 3. What concrete measures and
actions may be taken at EU level to support the development and growth of the EU
open-source sector and contribute to the EU’s technological sovereignty and
cybersecurity agenda? Support the creation of EU based full stack, open source
cloud service providers that can realistically compete with the non-EU
competitors. Encourage public organisations to cooperate with each other within
their domains to produce the tools they need based on a common core, and to open
source the tools they have already created. Support and fund security research
into public open source projects and security mitigation projects. Identify
critical open source projects, such as those underpinning other infrastructure,
basic functionalities, or those with very large market share and fund security
research and security mitigation projects to support those projects. 4. What
technology areas should be prioritised and why? Cloud Infrastructure, Operating
systems for consumer devices and governmental services. 5. In what sectors could
an increased use of open source lead to increased competitiveness and cyber
resilience? Supporting interoperability between different cloud technologies to
ease movement between vendors, even open source European ones, will create
incentives for those EU vendors to compete on quality of service rather than
another lock-in, and fostering healthy competition in the market. 1:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A01993L0013-20111212
[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A01993L0013-20111212]
2:
https://www.dw.com/en/ukraine-how-farm-vehicles-stolen-by-russia-were-remotely-disabled/a-61691839
[https://www.dw.com/en/ukraine-how-farm-vehicles-stolen-by-russia-were-remotely-disabled/a-61691839]
3: https://www.linuxfoundation.org/research/measuring-economic-value-of-os
[https://www.linuxfoundation.org/research/measuring-economic-value-of-os] 4:
https://github.com/CybroOdoo/OpenHRMS [https://github.com/CybroOdoo/OpenHRMS] 5:
https://github.com/markqvist/Reticulum [https://github.com/markqvist/Reticulum]
CivicoHub
vurk
Oliver Brendel
nicolaottomano
Sébastien
geartola
wierk
FoliumCreations
Pulse of Europe