Part II of II – Exploring Open Source as a Strategic Framework and how it is genuinely addressing Digital Sovereignty

This article continues thoughts and insights started in A Primer on Digital Sovereignty & Open Source Part I of II – Exploring the Digital Sovereignty narrative Motivation and authority on the matter For 3 decades I have been into Enterprise IT, having expertise at various layers of the “Digital Stack”. I did so always with a full life cycle perspective and made my lessons through related problems. I learned that my […]

Open Source is more than code and technology

Open Source is fostering Sovereignty in general from day 1 the idea existed. And Digital Sovereignty in particular.

Approach

Open Source is fundamentally a mental model which follows a well honed approach to solve issues:

Identify problems you share with others,
Gather as a group of likeminded, committed people,
Analyse the problem,
Start acting,
Refine, improve, share
Try to apply the solution
Asses quality and usability of the solution in an open and transparent fashion
Re-iterate as need be

Red Hat summarizes this in the five core open source principles–open exchange, participation, meritocracy, community, and release early and often–are outlined in Red Hat’s framework.

Classes of Problems

There are now various classes of problems to be applied. I am clustering those groups by the impact that problems have for individuals, smaller / larger groups, society or whether they can be used at scale and ease.

Whilst the starting cases focus more on solution crafting, consumption of the solution becomes much easier and appealing by the many. (Clustering is oversimplified and exemplary only – good enough to make my points, hopefully)

Individual, limited collaboration
Since ‘the dawn of time’ people grouped to hunt, farm, build shelters, houses and communities and benefited from being “stronger together”. Or making music, playing theatre..
[no sources delivered to proof :-)]
Effortful adoption that has broader reach
Others are writing books or teaching others that help to learn, apply new techniques and approaches that are supporting individuals or the society around them.

Those collaborations might be even possible by individual contributors, but they scale more easy and broader – but they need efforts to be adopted.

Things need to be understood, applying needs learning and practice but can help people to learn languages and drives business, intercultural conflict resolution, healing others, applying new methods to create tools, innovate and so on.

It could also be a plan to build things (invention of the wheel), source code that needs to be compiled or integrated into your own solutions before it’s ready to use.

Easy adoption / intense reach & scale of use
If you think about sharing music, software and easy to distribute, share and use, then consumption is becoming a lot more interesting to many and the benefit related to efforts to apply the results is extremely high.

Classes of consumption vs. collaboration intensity

Mainly, you can distinguish between those core types of dedication:

Consuming only
Consuming and giving feed back (bugs, improvements, ideas, criticism..)
Consuming & adoption for own needs
Consuming and innovating on top of what is there, for your own needs
Consuming & adoption that is fed back as a contribution
Consuming and innovating on top of what is there, and fed back as a contribution

It is key to understand that all those consumptions are important to prove relevance of the solution and that there is little to judge on the ways to consume – except that respect towards the folks that put efforts in should be give

Motivations to invest into Open Source based collaboration

Let’s get straight on businesses and organisations that need to invest into both collaboration efforts or consumption efforts, and skip the – in general very important – perspective on personal motivation.

Differentiation versus common capabilities and limited resources

Business and every other organisation needs to prove itself against others. The need for a unique selling point is true for all kinds of organisations. Let’s call this the need to differentiate.

On the other hand nearly all organisations share common problems to be solved.

And they usually have the constraint of both, limited resources of all kinds – and limited time to implement plans.

If you look at it analytically, there is a thin line between all capabilities needed in an organization that really create this differentiating effect above most common problems.

On the most common problem it seems logically, it makes total sense to consume solutions present that solve or help solving those most common problems. And if those solutions have an evolution cycle, it might even make sense to contribute a little to influence that evolutionary path.
You might want to do so to pay back a little, for reputation, to understand when and how to adopt the next evolution cycle or to skip one or two if adoption will take effort.

Or you want to create a new solution to a problem that is common in your “industry vertical” to reduce your efforts in an individual investment for a commodisable problem.

Open Source Software

If we address software being produced the open source way, you realize that most things started at a most common level:
The operating system. Why? Because it solves the most common problem that we all face.

We also see web server, developer tooling, test tooling, middleware of all kinds and internet infrastructure of all other kinds. Because they fall in the same category of being commodities.

The last years a close to complete cloud stack has been developed as the new “operating system” for data centres and edge/fog infrastructure management and automation. I want to highlight the widely adopted projects like OpenStack and Kubernetes amongst many other solution components.

You might ask why there are none or little core banking systems, insurance systems etc. developed with an Open Source mind set?
Maybe it is due to the cultural mind set of highly regulated industries or may be because it is hard to draw this line of differentiation and how to design an implementation for the strategists in those firms.
There are surely many other potential reasons, what makes it a good probe to challenge thoughts above against real world implementations of the strategy.

Open Source has Digital Sovereignty “built in”

As said in the introduction: I am working for one key player in Open Source Software, proudly!
Because: Digital Sovereignty and Sovereignty per se are on Red Hat’s agenda since day one of the company’s existence.

Starting our engagement with a Linux Distribution, we made high technology – not affordable UNIX for individuals or mid/small companies – available and consumable for society as a whole.

With our cloud portfolio we are doing the same for cloud infrastructure, might it be IaaS or PaaS, Cloud Management or Serverless Infrastructure services etc.

We are not the only contributors or players, but just a good citizen within the Open Source eco system, opening up and making proprietary technology available and easy to consume for all, always. The diversity of talents, communities, companies, authorities and many others makes this possible and the Red Hat Business model makes it possible to invest in talents and communities again. It is a perpetual cycle.

This provides security, choice and stability to others.

That makes you more sovereign on your digital strategy!

Enterprise Open Source consumption model

Maybe you are a small/medium business or you have a strategy to deal as little with IT complexity in house, or you like to delegate responsibilities into professional hands:

Enterprise Open Source offers you proven, assembled, hardened software versions, product roadmap, long product life cycle, compatibility, easy access, support,bug fixing, documentation and more with SLA and professional people to adopt these technologies.

No needs to make this from stretch by yourselves if you have the ability to observe, to detect options, have capabilities to plan and implement options detected.

This choice is also an aspect of Digital Sovereignty.

Final rant

If you are following the ideas, assuming that you or your organisation is involved in any international transactional value chains, transactions or working with international acting customer, suppliers, peers:
Open Source as a strategy is not bound on territories and it makes limited sense to consider initiatives that are adding a territorial constraint on innovating.

Open Source solutions need to be applied within (maybe territorial defined) regulatory context. But it is likely that current or future entities of your own or partners business organisation need to comply with additional regulations in other countries.

I tried to lay out what aspects related to consider.

May the source be with you!