What have I told you that in 25 minutes, you will be ready to join the first revolution and to contribute to our digital independence.
My name is Rosanna and I'm a digital product leader. I help people break free from vendor lock-in and build digital resilience.
I remember that day when one of my sea level colleagues called me and said with a very sad and disappointed voice.
Rosanna, we had another secured incident.
Be sounded helpless. This third party company providing close or solution not only build seven figure
invoices that cost secured incidents frequently. My colleague kind of challenged me and my team by asking,
Rosanna, do you think you would be able to propose an alternative solution?
The use case was very specific and not something where I would have had an unsell on the palm of my hand.
Together with my colleagues, we started the research, but we didn't find anything satisfying on the open source site.
Some of my team members even pitched the idea to stay on the closed source site, probably because of convenience,
but this was not aligned with our principles.
One of our principles was we prioritized the usual open source of a closed source.
And if you are serious about your principles, you don't compromise on them just after having some tiny difficulties.
Either you have personal principles or not. And especially in my role as a leader,
it was my job to remind my colleagues what really matters. So we didn't leave up.
On my way home, I wondered who my teams might be familiar with this very specific technology.
Suddenly, I thought of Nellie.
An open source human at heart. I called her and asked, hey, do you know anyone who is familiar with this stuff?
She replied, sure.
My colleague, me was an expert in the technology. So I asked if we could build something together.
And without hesitation, she answered, sure, I will be very cold, bye, and she hung up.
This was literally the whole conversation and how the idea of commissioning an entirely new open source project was born.
Digital sovereignty isn't just a technical topic.
Digital sovereignty is an important foundation of our democracy and freedom.
In the world, where fascism is no longer just history, but the day-to-day reality in some countries,
in a threat in others,
open source technology is more important than ever.
If you want future generations to live in every world, you have an obligation to contribute to the transformation from close source to free and open source software.
Europe's dependence on US big tech is massive.
The study commissioned last year by C. Griff found out that 80% of total spending on cloud software and services for business using Europe went to US companies.
Representing a volume of 265 billion European year.
Let's take a look at some examples from German public sector.
For Oracle alone, the German government signed framework agreements worth just under 4.8 billion euro.
German governments, Microsoft licenses and training contracts, account for framework agreements with a volume of 1.3 billion euro.
Just imagine spending that 265 billion euro, which European organizations spent currently on US software on open source technologies.
Cool, isn't it?
The money is out there. This is not the problem.
And seeing those numbers, we can definitely say that our infrastructure is already in trouble.
The cost of vendor-locking is way higher than the mentioned 265 billion euro.
We observe constantly raising subscription fees.
To give you an example, prices for geradata center for 15,000 users increase by nearly 150% within the past six years.
There is also the migration and data transfer costs for moving from one provider to another.
Apparently, the companies have some kind of separation anxiety.
And you probably invest in development of non-urusible skills.
So employee training and certification for a particular closed-sostec technology can be used only for this product.
Organizations trapped in the vendor-lock and lose the ability to easily switch solutions.
You might observe also gradual deterioration of technical and cognitive skills.
People who are trained to solve tough, technical problems can now only manage the certificates.
The most skilled people will be frustrated as hell and will live your organization.
And the dammer your organization will get the more difficult it will be for you to switch to open source alternatives.
This might cause innovation stagnation.
Because while managing closest environments, you train people to become Yamomankis and not innovators.
The ability to implement third-party tools and the usage of interfaces is usually very restricted.
You might even have difficulties to access your own data, you to dark patterns or API limits.
Data ownership is an issue using closed source, you're lacking transparency.
Do you have clarity if your top secret data is used for AI training?
Some companies claim that they use only the anonymized data.
Right?
But how sure can you be about it if you cannot check it?
Last but not least, geopolitical risks.
Do you want to wake up to find out that your sanction and can it use foreign products anymore?
A common argument is that outsourcing would allow organizations to focus on their core business.
But this golden cage in reality is a downward spiral.
And the only answer, the only answer to this golden cage of vendor-locking is free and open-source software.
Here's what nobody tells you about vendor-locking.
The reason is not made of code.
It's made of fear.
And the biggest barrier to overcome while switching to open-source alternatives is not technology.
But human beings in leading them through this change.
Technical problems can be solved with knowledge and patience.
But driving the mindset shift and guiding people under emotional journey of change is an endeavor with many unpredictable obstacles.
Transformation from closed source to open source is a major change initiative for organizations.
Gencopter found that about 70% of organizational changes fail.
So how do we actually make it work?
Principle number one, co-create, don't dictate.
Involve reduces.
Whenever I guide companies into migration process from direct to open project,
I always try to involve the real users from the very beginning.
Usually we start with mapping stakeholders and all of the use cases.
And I go on my uses island and try to understand their needs.
And if the solution is already there, I guide users during the transition,
translating their use cases to the new product.
Given the gap, of course, all the training they need.
In case the solution is not there yet.
I usually follow up with a deep dive research to understand their needs even better.
And you can co-create prototypes together with your users using rapid prototyping methods,
like design sprints with users literally sketched their own ideas.
So also test the prototypes together with your users to get a feedback.
And through this involvement, you will make them part of the new solution,
which will be happy to promote later on with the organization.
This is how you create ownership.
It's not just energy solution, which was thrown over the fans by their IT department,
but they want to co-create themselves.
And this is where the IT effect applies.
Bill Champions find your elderly adopters and power them.
Mapping all of the use cases within a bigger organization can be very time consuming.
So think about ways how you can create a network of champions who will be taking all the parts of the research process.
You need the champion voices to be spread across the whole organization to make this change happen.
So build this champion network early in the process.
And believe me, in those methods scale, within one of the organizations I was leading for change,
I managed to build a co-creation process with 1,000 end users.
And of course, involve decision makers.
Because without their support and without the proper mandate, you won't be able to pivot at all.
This brings me to the next topic.
Principle number 2, change by education.
Educate stakeholders and open-source.
Not every executive is within our false bubble.
So try to understand their fears and address them.
And be prepared to address all kinds of myths on open-source.
I will share with you some real quotes.
I have multiple times among sea level and various industries.
So please fasten your seat belts.
Myth number 1, but open-source is not secure.
Here we go, open-outting.
Open-source actually benefits from a large community of developers who continuously improve the security.
And every person, including you, can review the code and fix the box.
No feature IDs.
A phenomenon called feature IDs occurs when managers build feature factories
and make pressure on the teams to deliver one useless feature after another.
In first project, you will often observe a mindset where stability and security are prioritized of a delivery of new features,
which is a very sustainable mindset for product development.
So instead of going fast and breaking things, go slower and fix things to go faster.
Myth number 2, but there is no one I can rely on.
So I don't know who you are.
Sign contracts with maintainers and contributors of very professional support for the first project of your choice.
You can go for a simple support contract, you can commission some features,
or you can commission entirely new project as I did it in the past.
As one of my colleagues has, if you want to be lucky, install the software.
If you want to be successful, sign a contract.
Very often you will have multiple maintainers and contributors supporting the first project you want to implement,
so you also have the freedom of choice who you want to work with.
Usually using big tech, you are a very anonymous user.
Within the first project you have a high chance to be a very relevant user.
So being part of the first community gives you the possibility to co-create and shape the product.
Very often for example, interviewing our users to understand their needs, how they use the product,
and I involve them on a regular basis and prototype testing.
Myth number 3, open source is free.
There were three and three and open source indicates the freedoms which are enabled through force,
free to use, to study, to share, to improve.
If you want the project to be successful and to be maintained long term, make sure the developers can also pay their bills.
For many being an open source developer is a regular job, which should be paid for.
It's not a hobby.
Public money, public code.
Especially public organization should be considered while making decisions on how to spend our tech's money, right?
Is it even compliant to pay way more if you could pay way less?
Myth number 4, there is no alternative for this use case in open source.
I cannot hear this one anymore.
This is my personal trigger to be honest with you.
I switch fully to open source on my computer.
I don't have any closed source installed and I'm still alive.
Very often it's a decision between make or buy at the sea level.
I would add a new dimension to those decision making processes, make, buy or commission.
So if some features are missing, go and pay for it, contribute with your team or commission entirely new project.
So that no one else in future can say there is no alternative in open source.
And remember, you can make the change happen, especially if you're a decision maker.
There are also doubts which some CIOs think aren't afraid to say out loud.
How will my colleagues perceive me if I roll out this open source thingy and not big tech?
Unfortunately I've served this one very often in the CIO bubble and the big tech companies are really good in marketing and building this narrative.
Oh, so many other companies trusted us. You can trust us as well.
So either you have your own brain and courage or not.
Don't be afraid to be a first mover in your bubble.
You can set the tone. You can inspire people.
So be like the excretar who is literally driving a revolution in Schleswig-Holstein and switching one use case after another to false.
Who can I blame as something goes wrong?
I don't want my hat rule.
To me as a person interested a lot in organizational culture, this one makes me very, very sad.
So you can start changing your culture, but this might be tough.
And of course, sign a contract with the contributors and maintainers behind the first project to have a professional relationship and to support the project long term,
because they can survive only with your long term support.
Me and my team are not skilled to run it.
Sorry to say, but this is a self-inflicted issue.
Indeed, if you were outsourcing technology in the past years, this skills got lost.
Yes, this is also what the close source companies want.
And this is also a consequence of the vendor lock-in.
So if you really don't have the skills, train your people, hire new people,
and hire small people who are open source people at heart, and allow them to do their job.
Do your job advertising on Massodom, rather than on LinkedIn, because you will find real open source people rather in the Fedivers and on LinkedIn.
Plus, teams usually have many obstacles to overcome.
So as a manager, do your best not to be your team's biggest obstacle.
Don't micromanage them, and then allow skilled people to make decisions they were trained for, too, and hired for.
Otherwise, indeed, the smartest people will leave you.
Managers being they have to involve in every decision.
True leaders know that their job is to empower others.
So don't be a manager, be a leader.
Principle number three, lead people, manage things.
Change can be scary.
As a leader, your main job is to guide people under emotional journey of change.
Recently, I was running a proof of concept for a big public organization.
They started the migration from Gerat to Open Project.
So I went under Ireland to understand their processes and ways of working.
I was curious to hear their fears.
And this information not only helps me to translate their needs into Open Project,
but also builds trust and relationship with the Open Source community.
Listen.
Listen with the intention to understand and help.
Be curious and not judgmental.
And remember, feedback is a gift.
People undergoing change might have very valuable feedback,
which will help you address their risks very early.
And create environment based on psychological safety,
where people are not afraid to share their doubts of fears.
Only when knowing problems early, you can address them effectively.
So create spaces to share feedback and ask any kind of questions.
And inspire and lead by example.
You are driving the mindset shift.
So lead by example by installing Linux on your machine by switching to Open Source alternatives as a first mover.
So how to break free from vendor lock-in and drive change to what a resilient infrastructure.
Co-create, don't dictate.
Lead change by education, lead people, manage things.
You might ask, Rosanna, if the change is so hard, why should we even bother?
1,421.
This number shaped my mindset and was part of my childhood experience.
During World War II, my grandfather was held as a prison of war and the Althelek 2A.
A German prison of war camp located in the town of Prince Lo.
For me, my grandfather's tattoo is a symbol of why we need justice and freedom.
Especially public organizations have the obligation to improve things for our society.
But even if you're a private organization, you can co-create the public infrastructure if you contribute to Open Source products.
Especially if you're a decision maker, you can make the change happen.
So start the transition to Open Source that prepared well.
You don't have and you should not do it alone.
Co-create the future together with your colleagues.
Digital sovereignty isn't built with code alone.
It's built with people.
People who believe in it.
Switching to Open Source is the best thing you can do to your organizations, your colleagues, your users, and us the citizens.
So Monday morning, please pick one product.
You can replace with foster technologies and start planning this transition to get away with your colleagues.
This is a hard work but a necessary work.
You're not just migrating software.
You're building democracy and freedom for future generations.
Thank you.