Beyond the mobile duopoly: open ecosystem, open language - Eclipse Oniro and Cangjie

This talk, presented by Jaroslav Marek and Professor Dan Gica, explores the concept of digital sovereignty in Europe through open-source technologies, specifically focusing on the Eclipse and Kanji programming language. The speakers discuss the implications of geopolitical changes on technology dependencies and emphasize the importance of developing independent systems. They highlight Open Harmony as a viable alternative to traditional mobile operating systems, detailing its rapid growth and ecosystem, including over 2,000 certified products. Additionally, the talk introduces Tang Jaime, a new programming language designed to streamline app development within this ecosystem, featuring characteristics similar to Java and Swift. They also address how AI innovations are transforming app development processes, enabling easier and faster deployment of applications, which is crucial for fostering a robust digital environment in Europe.

Hello everyone. My name is Jaroslav Marek and together with uh Professor Dan Gica, we'll take you to the world of Eclipse on your operating system and Kanji programming language. There were ongoing discussions in Europe for years about digital sovereignty, but the risk was just theoretical. For years it was theoretical, but something has changed last year when US sanctioned uh prosecu- prosecutor of International Criminal Court. And because

of that his access to Microsoft services uh has been disrupted. It was widely noticed. So, something that was theoretical became real. Um we'll have a wave of actions in in countries across Europe to replace uh technologies that are linked to most of the time uh US entities and build digital sovereignty. Uh the goal is to be independent and the way to do it is to through open

source. Europe is capable of doing that. We have multiple open source projects which may not be as major as advanced as commercial services from US companies, but they proved to be good enough. Uh very good and almost all elements of software stack are covered. Uh either document editing, messaging, video conferencing, you name it. Uh for PCs, we have an answer in terms of supporting the hardware. Operating

system is Linux. I think this is obvious for for for all of us. But, there's no clear answer what should be the operating system of mobile devices. There are I would say there are two categories currently at the moment. Open source categories. One category is for is for operating system that are Android-based or non-Android-based. So, literally based on Both of the these have uh own strengths and

weaknesses. The problem with Android-based is that uh although AOSP is an open source project the governance uh model of the project make it dependent uh on the on a single company. Linux-based operating systems don't have that problem. But, the reality is that their adoption rate is is uh uh limited. There were attempts in the past to build commercial mobile uh operating systems and distribution that could compete

with existing duopoly, but all of them failed. All of them failed. Uh whether was it Microsoft that was working on it, BlackBerry, Mozilla, uh Samsung, or HP with webOS webOS. All of those attempt failed. There were many reasons for that, but there was one uh major reasons for it. It was a chicken and egg problem. There's a vicious uh circle of dependencies. If there are no users,

there will be no developers. If there are no developers, obviously there will be no apps. If there will be no apps, there will be no users, and the circle closes. what we noticing recently, there's an opportunity windows that is uh showing up. Uh AI is changing the way how apps are being developed, and introduces development cost greatly. Uh research says that currently like almost all developers use

AI in some forms, either very very very basic one with some syntax uh helping to the very advanced usage, where we use AI agents to actually create parts of parts of the code. some researchers say that around 40% of code created these days already is being somehow created with with the help of with the help of AI. And this affects creation cost, especially that LLMs used used

for that are getting I mean which uh acceptable level. Uh the the cost between the starting GPT-4 and uh mini was like 200 times uh lower. And those tools are getting better and better. Uh it started with just simple code auto complete syntax prediction, But, we are currently at the level of uh prompt to app uh when you can just uh with a few uh prompts generate

an app, scan QR code, and then will land on uh on your mobile device. Those solutions already uh uh exist, and it is expected that uh soon in few years uh for now mm the final uh platform will be just a a configuration choice uh choice. You'll just uh prompt it to say, "Okay, uh create me an app for this platform or the other platform." what we

already know is that uh Europe uh needs proven foundation and local governance for the digital uh sovereignty thing uh mobile operating systems. Sorry, yeah. There's an alternative to Linux-based and uh Android-based operating system, and this is Open Harmony. This is this a system operating system that has been created uh 6 years ago, 2020 it was uh started. Uh it's an open source project governed by uh open

source foundation called uh uh OpenAtom. And for the last 5 uh years there was enormous uh growth of of uh of the project. There more than 13 uh thousands uh contributors, hundreds of community partners, meaning contributing, more than 70 interest groups. And there are already almost 2,000 uh certified uh products. this is a base on which uh other distributions are being uh created either commercial ones or

open source ones. For commercial Huawei for example based its HarmonyOS next operating system on OpenHarmony. In Europe Eclipse Foundation owns and governs Eclipse project which is also a distribution of To prove that it's viable platform to build products on we can look at what Huawei did with uh with distribution of OpenHarmony called HarmonyOS next. Uh those products are available from around a year and a half. First

mobile phones has been introduced to the market in 2024 November. There are set of phones already available only in Chinese market. Uh but we would unique form factors. Last year a PC notebook has been released to the market. very again very unique form factor foldable. I think it's the only in the world. If you want to see it definitely worth seeing it. I invite you to our

Aneu booth uh to see how it how it performs. Um but those are products available in China. uh we can see how the products based on this operating system works with watch 5. And currently there are more than 50 millions of uh uh devices based on this operating available in the film in the field and what's worth mentioning there already more than 10 million developers uh, developing

applications. Uh, I mean, registered uh, developers. So, the the platform Open Harmony is strong enough to build reliable uh, products. But, let's uh, let's get back to to to our field, Europe. Uh, in Europe, uh, we have open source project governed by Eclipse Foundation called FIWARE. It was uh, created uh, 5 years ago by a set of European companies. They created a project and uh, and a

working group to basically give Europe independent access to the strong uh, Open Harmony ecosystem. Shortly after creation, those two foundations uh, Open Atom that uh, owns uh, Open Harmony and Eclipse Foundation that owns FIWARE, uh, signed agreement uh, as my Mike Milinkovich uh, stated executive director of uh, Eclipse Foundation, that was first of this uh, this kind agreement between uh, two open for joint development uh, of

of worldwide uh, ecosystem. And what is Eclipse FIWARE today? It's built on fourth uh, four pillars. Uh, the key one philosophy for uh, for FIWARE is uh, think global, code local. So, make a global ecosystem, but developed locally. because of that, four three other principles uh, follow. For local development, uh, FIWARE cooperates with uh, local partners to enable technologies and software components that are used to uh,

locally, adapts to local uh, regulations, and to provide this global access uh, to to to the it's it stays and declares to be compatible with with the upstream project. So, with uh with Open Harmony. How are we going to close the gap of uh applications for for for the new completely new software stack? the difference between previous attempts software stack already suc- succeeded it uh region of

the world. So, so the upstream uh Open Harmony already succeeded in China. So, there are plenty of application, but we should focus on local uh local uh markets on on on Europe. So, what we are doing is we we take we took approach in like three directions. One is to port cross-platform frameworks because of the ma- multiplier effect. If we have uh cross-platform framework, automatically all the

apps created for using that framework are available on Um another I think this is open source project. So, we look for also open source app, uh popular apps. And with the help of AI, we are capable of quickly porting this those apps to uh the new software stack. And we proved that it's uh it's really doable uh within few months this year. We ported VLC, Telegram, uh

Signal. Um there's obviously also an element of new innovative apps, open source app. The way we do it, we uh provide to the the tooling, development tooling, also documentation but this localized also called light code labs examples so to to to rely on. And where are we heading? Our goal is to further drive adoption and ecosystem growth. So we what we concentrate on is promoting the system,

demonstrating it. Lowering barriers to developers and also to companies willing and communities willing to participate in this great effort we cooperate with service providers companies to build a strong European foundation. That is that sits here in Europe and is lacking dependencies from from the regions. this operating system supports multiple programming languages that are available elsewhere but also introduces a new programming language that will be demonstrated but

by by Professor Ika. Do we have a clicker here? We don't. I don't. You have to Okay. Hi. My name is Dan. It's a pleasure to be here. The main development language right now for the on your platform and for open harmony is a fork of JavaScript of actually more precisely of uh TypeScript called RTS. And one thing that was kind of missing from the picture right

now was an application level uh programming language on the lines of let's say Java or Kotlin or Swift. And that programming language is called Tang Dee. Was uh it has been under development for quite a few years, but it has been open-sourced Uh so, you can you can try it out for yourself. Um it it doesn't have like right right now, it's not formally included into this

AOSP distribution, but that's hopefully something that it will be um happening anytime now. this programming language has been developed mainly by people at Huawei. And the reason why it's good to have your own programming language is the same reason that, for example, Apple has its own programming language Swift. And that is not just because you think, "Oh, I'm going to make a programming language that's like unlike

anything the world has been seen so far." but because a programming language is a glue that binds together your software stack to your hardware. And Huawei is a like Apple is a very vertically integrated uh company that makes everything from silicon all the way to consumer apps. And again, the latest uh kind of addition to the to this ecosystem to this full stack was um an application

level programming language. So, an does not mean just a language itself, but the entire ecosystem of tools that happens to that's needed to support that So, I have been part of that team based in Edinburgh, but uh there are many teams that work on this project in uh the main team is in Hangzhou in China, but also in Shanghai and in other research centers uh in China.

The name Cangjie uh comes from this mythical character who is the inventor of the Chinese script it's not very easy to pronounce in English, so sometimes we refer to the Cangjie language as CJ, uh which sounds a little bit more uh palatable uh to the just people who speak English and also the it matches the file extension when you write uh uh such a such a program.

it has been developed by the language has been developed by Huawei, but it's now uh open source. It is general purpose, it is high-level, expressive, safe, quite similar to other languages uh in these brackets such as Kotlin, Java, or uh Swift. Statically typed, which means it's both safe and it can be efficiently compiled, unlike languages which use dynamic typing such as JavaScript or um or or even

TypeScript because TypeScript, even though it it has static typing, it retains uh some dynamic aspects that make static compilation a challenge. It is type and memory safe, so you shouldn't have memory leaks, you uh null pointer expe- exceptions and stuff like that. If you have them usually it it it means there's a there's a bug somewhere. Um but they shouldn't uh they shouldn't happen uh by construction.

uh garbage collected and it has a concurrent garbage collector. It has a full-fledged um garbage collector unlike languages such as Swift which use um uh like reference counts. So, this is like a full-blown concurrent garbage collector which has good level of performance. And it has several backends. So, you can write the program and then compile it on Linux. You can compile it on Mac OS, Windows, Harmony

OS. So, you can already compile it on pretty much all the devices uh that you have seen uh so far. And uh those are the links where you can uh you can access it if you want to uh just have a go at it, see how it feels. Right. So, as I said, there's a lot of work in developing a programming language because a programming language the

compiler. Uh there's a lot of stuff that you have to do. Uh you have to develop frameworks to be able to produce apps like UI frameworks, testing frameworks, and so on. Language SDKs, uh APIs for interfacing with the operating system uh which actually Harmony OS has tens of thousands of uh of functions in the API. So, all that has to be supported. for testing, for benchmarking, for

test covering, debugging, and so on. All that has been developed. It's a um it's obviously it's not a mature ecosystem because it's only been uh made open source last year, but it is it it covers already the breadth of what you would expect a mature programming language to cover. And also you have to produce the runtime and the standard library to interface with the operating system. Yeah,

so all all that infrastructure is in place. And you can write serious um programming serious apps with it and there are already quite a few uh apps developed in the HarmonyOS Next ecosystem using uh using um uh using Tangjia. Probably our most kind of most successful partnership is with Meituan. Meituan is a big company in China that uh does deliveries. And uh their app is now mostly

on HarmonyOS Next is mostly written in In China there is also a very vibrant uh ecosystem uh that involves universities, teaching, and the open source community. There are a lot of open source projects uh for for Tangjia. Uh many universities, more than 80 universities are either using it as a teaching language or they're planning to use it as a teaching language. So just like just like with

OpenHarmony the ecosystem in China is uh is very robust and it is in some sense enough to guarantee the long-term viability of the language. Uh because one of the things that worries people the most when they commit to a programming language is like, will this language that I'm committing to will it be around next year, in 5 years, in 10 years? And this language will be around.

It's It's already uh quite established even though new in uh in a very large market. So, here is a uh like-for-like comparison of our language other language in the same bracket. And because we are kind of new to the party, we could just pick and choose the best features from other programming languages. We are at the time unburdened by legacy considerations, by existing customer consideration. We could

really put in everything that we thought would be good to have in a programming language. So, we have algebraic data types. I I quite I quite like the support for algebraic data types in uh in in uh in Tangram. what are the things there that is um that are um let's say quite nice to have? Well, we have we have a very strong macro facilities. There's a

a lot of uh um effort that was uh invested to to have very flexible support for macros. I'm not a big fan of meta programming myself, but uh you know, people who like that, go and use it. Uh what I am a fan of and I'm going to talk a little bit more is this thing at the bottom called effect handlers. Other than uh you who has

heard of effect handlers? So, effect handlers, uh we are very very happy to be able to include effect handlers into the Tangji programming language because you can see that is one point of distinction between Tangji and other uh similar programming language. So, that was Oh. In case you haven't seen uh in case you algebraic data types, if you are um somehow um uh if your predicament is

to be a a Java programmer or a Go programmer, uh they look they look very nice. They look like this. So, you can do on uh on complex data types such as trees, you can do pattern matching which are uh which is tested by the compiler for coverage so that it's exhaustive uh and uh and uh complete. So, so that is Yeah, for exhaustiveness. So, uh you

can write structurally inductive programs just like uh or structurally recursive program just like you would do in uh OCaml or or Haskell or other functional programming language. Very elegant. But, what I want to talk a little bit more because that is uh more likely that you haven't seen is effect handlers. So, effect handlers have been researched very intensely by the programming language community in the last 10

to 15 years. There's a lot of papers. Luckily, or maybe not so luckily, maybe that was kind of the the reason why I was uh influenced is that uh they originated in Edinburgh. Uh and probably you were around at the time of uh their genesis. they have been uh kind of the motivation behind effect handlers was to add a ways for funk pure functional programming languages to

uh interact with the world and to interact with their context. Before the standard way of interacting with the world or with the context of a functional programming language was via monads. Who knows about monads? Who has heard of monads, the word monads? No? Okay. Um monads have somehow of um uh they're like a very big feature, a very big thing particularly in in Haskell. and they have

kind of people like to love them or hate them, but in fact they have some um technical shortcomings that I'm not going to get into it, and effect handlers were intended as a way to overcome that their limit the limitation of monads. they did. But in the process, like okay, I'm doing all these kind of um all these kind of theoretically driven in the end they invented

something which is a new programming language feature that many people, including myself, asked, "Uh would this feature be useful not just in a functional programming language, but in any programming language that already has other ways of uh with the environment?" the the answer is yes. So, one way to understand effect handlers very uh very is that they are a generalization of the way they're presented is a

generalization of the concept of exception. So, here on the left you have a concept of exception, which is the standard concept as seen in many languages where something bad happen, in that case uh an attempted division by zero and then you throw an exception. people say it's called a throw an exception because it goes up your call stack into the context. You don't you expect the context

to somehow deal with So you throw it into the context. It's going to be it's going to be caught by some handler which is up in the context. And then the handler the only thing that the handler can do in a with a normal exception is to find a way to exit that error situation gracefully, clean up and exit. Now effect handlers are different because they give

the context the ability to actually deal with that problem deal with that situation and then continue as if nothing happened. So you see here at the bottom there's a new keyword that says resume with something. So if I find a division by zero in that particular context, I can decide it's not catastrophic. I know it's not correct, but I can just return zero and I can carry

on. Maybe uh maybe there's a function that is computing your next favorite song by Spotify and you would rather get an imperfect song uh uh rather than the whole app crashing. So you know, that's the kind of situation where it's okay to just make up a number and carry on. So that's the the key distinction is that an effect it allows you to resume uh an exceptional

situation. And because it allows you to do that, it allows the programming language to revisit completely the concept of dynamic binding. Most of the coding that we like to do using conventional programming languages is to use static binding. So, you have some code and you want to perform some functionality, you call a function. So, that means you go down into a deeper context and then you perform

some operation and then that operation is going to um is going to give you some value. And that you can do it both for the purpose of computation, but also for the purpose of interacting with the system via foreign functions like printing and stuff like that that access your machine. But sometimes, the context is not known. Like you don't know so like an example that I just

gave you, that you don't know what um what the uh you don't know what the context is. So, if I make a a division and I get division by zero, now whether I kind of fly the space shuttle or whether I'm performing my next favorite Spotify song, these are very different contexts. And my approach to what should happen if this illegal circumstance arises is going to be

very different. That can only happen if I throw that error or if I send that error up to the context to deal with it. And that is what essentially uh dynamic binding is. So, dynamic binding in instead of calling a function, which means go down, you ask the context uh which is up in the calling stack to deal with it. And um and this is actually in

in there's a lot of dynamic binding frameworks because you cannot basically do a dynamic binding library just by definition. The libraries are always go go into the stack, whereas you want to go up into the call stack. And the dynamic binding libraries that you find for Java and so on, they tend to be quite big, quite um monolithic, kind of over-engineered, because the language does not have

native support. So, they end up using bunch of meta-programming, reflection, ways to get around the fact that the native support does not exist. But, with effect handlers, you have these abilities. So, for example, the hello world of dynamic is logging. All right? You want to You want to write uh You want to have a framework that where you log things. But, the the concept of logging is

very loosely specified. So, imagine that you write a library for a framework such as Oniro. So, you That library can run on a laptop, on a mobile phone, uh on a watch, uh on some kind of IoT device that has you know, it doesn't have not doesn't have a screen or doesn't have a hard drive or doesn't have a console. There's no standard way to do logging

across uh across all platforms. So, then what do you do? Well, in that case, you need to use dynamic binding. Whenever your code needs to log something, then you need to inform the context saying some logging needs to be done. And then the context will know how to handle the logging, but also, unlike an exception, you need to be able to come back. You don't want to

just throw an exception and and quit your execution. You want to perform that logging in a way can which is controlled by the and then resume the uh computation. So, for example, on a desktop here, you can see that you're performing some function, and that function performs a log. And in the handler, because I'm on a because I'm on a desktop, I have a console, so I

can just print to the desktop. I can just print to the uh to the console. Whereas, if I'm on a mobile, the mobile doesn't have a console. So, then if you want to do the logging, maybe you decide to just open some kind of alert that presents that log, but also you could send it in an email. Um or you could just ignore it. You can do

whatever you want. The context can decide as appropriate. Um and that can that really is all that there is to it to logging. You can do logging in three lines of code. Now, try to do the same thing with a language without effect handlers, and you will see that is significantly uh significantly more uh complicated. uh we have some more uh worked out uh frameworks using uh

effect handlers. Uh One of them is for logging, but also there are other things that are a little bit more complicated, but I I'm not going to to to go into too much technical exposition right now. But if you go to the the library of uh kind of quasi-official third-party component, that's what TPC means. For Tang Jie, you are going to find uh a few libraries using

uh effect handlers there. uh this is the end of my talk. Thank you very much. If you have any questions, let me know. Or also uh Yarik didn't have time to take questions, so also you if you have questions for him. Yes? Very much. That's very interesting to see both the language, a programming language, and an operating system being at the same time. As someone I think

kind of famous used to say, if you design a language, an operating system is a collection of thing that is not in the language, and it shouldn't be one. I think that's Alan Kay. Sorry, what? I didn't understand. Um I know I see it cuz it's a collection of thing that you can't fit in the An OS? Yeah, operating system. >> It's a collection of things that

you cannot fit in a programming language. Maybe it's a collection of things that should not you should not fit in a Maybe. >> I mean for I don't know when Alan Kay said that, but Fortran had a lot of stuff in the programming language like all the input-output was built in to the compiler. I don't think anybody thought that was a good idea, and everybody was happy

when C came along with an ABI and pushed everything outside of uh out outside of the language including essentially memory allocation and deallocation, which were presented as kind of standard library calls even though they were essential. Mhm. That's that's the world of language has changed, and we see Fortran now as something simple. Well, simple as a language but not simple as a compiler. As I said, it

had the input-output drivers built into the compiler, not into the operating system. I mean operating system modern operating systems such as Unix were invented after mod after like Fortran. I mean Fortran reasonably modern. It's you you you would recognize it as like if you see Fortran code, you can read it. Uh it's not like if you see assembly code. Uh and that's older than Unix. So, I

don't know. When did Alan Kay say that? Do you know? What's the date? >> Probably in the '80s when he was creating Smalltalk. I see. So, one one of the question is um you said that one of the thing uh the Harmony OS uh managed to do is to um get out of the duopoly. But, I think I would like to question whether something has to do

with um the fact that in China and in part of uh we have a different view of the apps ecosystem than in Europe. And especially we have these super apps concepts where basically uh the main layers you have with a lot of the apps in China is through WeChat or something else and not through the OS. So, once you say that you have on a new platform,

that meant means you get along a full ecosystems and you're not like on the uh space where you have to deal with all the banking apps, all the ordering apps, all the etc. So, you you're talking about an ecosystem that before the advent of Harmony OS has learned to decouple itself to the way it's shaped in Europe and in the US. So, how much of that uh

allowed to break the duopoly? And how much of that would not apply into the European ecosystem? I think I mean, there's nothing so much different between applications in uh China and others, but they're absolutely right. our local environment is absolutely different because of so many countries uh so many different apps. it's it's not that simple even in China to reproduce the the the ecosystem. There here it's

even more complex. But the thing is what I uh shown in my pre- presentation the the whole paradigm uh of application creation uh changes with with the rise of AI. It's it's it's got much much easier to deploy new apps up to the level that it's expected that uh there could be even at the moment you can have either very complex apps. And AI is not ready

for it. AI agents are not ready to reproduce like uh commercially available apps with millions of of users. But we're I think we're slowly progressing to the world where we'll have we'll consider apps as just uh mhm a tool. Just a tool, local tool uh that will be generated on the spot. and if this will be for for a single that will be customized app and doesn't

have to be in the perfect even. It doesn't have to be very extensive. It will be just whatever you you need to accomplish on your uh on your portable device uh it will be on the spot generated or or just some solutions in advance. And that may solve the the the the issue of lack of applications generally uh available as as they are now. Uh but either

way uh since uh we're in the position in Europe but that we're being forced uh somehow being forced to creating the independency. So that's that's that's the way to go. We are forced to find a solution to build ecosystem. What what what else remains? Full dependencies. Uh full dependency dependency on on the external ecosystem. Together with uh set of companies in Europe that uh uh that tried

to to to build local European ecosystem where working on uh ideas and and solutions how how to detach these dependencies especially as US companies are more and more locking down to to to this system. There's initiative currently from Volla company for from from Germany for uh unified attestation to to have open source uh basically uh uh open alternative to uh to Google attestation of of devices because

on one hand Google uh enforces it to uh to give another layer of security but through that activity it locks more and more apps to to their system and services controlling whether this particular app can work on this particular device. So, it it builds another dependency. So, there are a lot of efforts currently in Europe to to build alternative solutions. So, uh it's not even controlled by

a single entity but but it's open and we we it's not being controlled by by a uh by a single vendor. I and I I think the same considerations apply to a new programming language I subscribe to the view that agentic programming is going to become prevalent very soon. And with agentic programming the programming language is the new assembly code. You don't really need to look at

it. You need to understand it. You don't need to look at it so much. So, then what's important is not the language itself. It's not like, "Oh, does it have does it have this keyword that's prettier than that keyword?" That doesn't That becomes totally irrelevant. Nobody makes these kind of ergonomic considerations about assembly code because we know that's produced by machines for machines. And the same thing

is going to happen with But, what is important is then the set of tools that support that programming language. The compiler, it's important. Uh the the the all the other verification tools, testing tools, because the the the the agents will never be able to one-shot an app. They will have to interact in a kind of iteratively with the tooling ecosystem to make sure that the pro the

produced code is correct. Uh and that tooling ecosystem is going to be very important. And that tooling ecosystem will always have to be well integrated uh with a particular platform or another. And I just like if you if you want to produce an app for uh iOS, you would be foolish to like not use Swift. Just use Swift. It's good enough. Whether you do it by hand,

even more so if you want to do it with an agent. Um and the the same considerations here, having a a tool a set of a complete set of tools that is open source, that has a permissive license, that is not going to be used as a choke point by various uh kind of political um contingency needs, I think it's it's very important because even though this

ecosystem in principle can be reproduced, they're actually it's not so easy to reproduce it even with agents. I mean, if you look at the you know, if you look at the amount of Where Where is it? Yeah, if you look at the amount of tools and amount of frameworks uh and the runtime support that you need for a programming language to work, it's a lot and you

don't want to have to replicate uh that environment and you don't want to be um constrained by that environment. And one reason that obviously, I don't know if you're like uh watching the news very carefully, but there have been all sorts of uh choke points uh here like at various points produced uh against Huawei and programming languages have not been used, but they could be used because

uh these kind of application-level programming languages, they even though they're open source, they're the licensing of them belongs to various American companies. kind of the terms of open source can always be preempted by export control. So, they can always be at least theoretically used as a choke point, even if they haven't. Um so, that's why it's important to have a technology stack where you are uh where

you are free of this worry. It's It's not to make the life of the developer. So, maybe like our point is that this is not to make the life of the developer easy. The life of the developer is going to be harder, but there is enough support A, for that life not to be impossibly hard. It can be done. And B, there is enough motivation uh to

in order of having technology independence. Just from the point of view of Europe, you're you're arguing to to adopt uh you know, a big ecosystem of originally Chinese origin. I'm then arguing that it's kind of safer, there's fewer risks of choke points um than relying on American tech. Um so, it's true that this is all open source, but um as as you say, I mean, to actually

use this, you need access to streams of bug fixes and releases and so forth. Um and is that really Can Can European companies really trust that that is not going to be cut off at some point? Maybe you can explain better how the Oniro governance basically, Oniro is is a downstream of Open Harmony under governance of Eclipse Foundation. And the thing is it's The main point is

compatibility. Uh if anything happens with the upstream, downstream can can continue uh to work. Because the only thing that is guaranteed between uh two of them like is like uh uh compatibility. Uh whatever works on Oniro will also uh I mean, whatever works on Open Harmony will also work on Oniro. So, the app can run uh on both of them. But actually, technology stack uh uh can

be even replaced if you wish. If you just maintain uh the same uh specification, like a compatibility uh specification. So, whatever happens, even in the upstream, you are free to adopt anything. Interesting. I mean, like compatibility is nice in in in the abstract, but in practice, it's often pretty difficult to you know, truly have compatibility between I don't know, different providers. So, uh I think a a

bunch of due diligence would be needed, but yeah, thank you. I think we're out of time. But thank you