My response to European call for feedback on open source - Lemmy.World
cross-posted from: https://lemmy.world/post/42619499
[https://lemmy.world/post/42619499] > 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]
