#220 - From Hibernate to Quarkus: Modernizing Java for Cloud-Native - Sanne Grinovero

I completely hated these technologies initially. Java seems large, low 30. The way cloud native development was going, it was clear that the direction Java was taking was just not compatible with this new feature. There was a strong concern that the Java would still be alive in 10 years about. Java back then people associated as a heavyweight. Has Java become a valid choice for like cloud native application? We do have a quarkless version for serverless.

It starts in milliseconds. How do you compare Java now with my modern programming languages Rasco? What are still some of the strengths that Java has that people should consider? They honestly think Java is in a very very good position. People maybe don't realize it, right? At the moment, if you're still active in the hibernate, how many contributors are there? We just changed the license of Hibernatorium.

We had to contact every single contributor ever that made some meaningful contribution for projects. It's like more than 2000 contributors. There's such thing as politics in open source project. I think there is, but there certainly are strong opinions. Many programming languages now support some kind of ORM library. Some people like it, some people really hate it. What is your opinion? There are lots of hybrid haters, right?

There is a large group of people that sadly have been both hybrid at the wrong way. And then of course, there is a category of people that's. ORM widely adopted. When do you think it's not the right time to use like ORM or Hymony? I might be biased. I would always start from. Hello guys. I think this is our first time having technical journal recording, in person podcast recording. So as the first honorary guest, we have Sunny in this studio

today. Sunny is a long time open source contributor with Hibernate, Quakers and an infinite Span, so many projects. He has been a long timer in Red Hat as well, probably about 16 years. And he is travelling to Singapore. So we had a good chance to actually speak to him and ask him about his journey. So welcome to this first in person podcast recording, right Sunny in the beginning.

I always love to invite my guests to maybe share a little bit about your career, especially turning points that you think we can learn from you. Yeah, yeah, fantastic. So when I was at university, I was in, in Italy finishing my studies and I once, you know, professors had, they would assign students to some practical jobs as well at the end of that. And so I got involved into a big, very large Java project, which was using a Java enterprise at the time deploying on Jboss.

I completely hated these technologies initially. Like it was like, oh, Java seems large, bloated. It takes ages to deploy something and get feedback like I'm on the right path. Of course, everything was new to me. And so the fact that to to know that some code that was actually going to work as expected needed to go through this entire cycle of deployment, that was painful.

So very quickly I put down scripts to deploy this faster on the application server and you know, to, to do all these kind of things and you realise it's open source and you can read it. So you Start learning a lot about the platform and how to work better with it. And well, that project, it went from being extremely large and slow and complicated to something that I really like doing.

And so very quickly I was, I became from being like the junior guy that Barry knew some Java to actually lead the project. And then well, there was a bit of a competition, like a Red Hat was looking for interesting use cases to share to their customers. And so I wrote down what we had done with the project and we won an innovation award. So they sent me to Orlando to

get this award. It was a bit weird because I was like very young and suddenly and they are between all the, you know, these guys that are my heroes. Like these are like the Java developers that actually created these technologies. But they were all like very like level where they they would, they were interested to hear my about my experience and then also about the problems that I had. And then, you know, they immediately started brainstorming with me, Oh, how

can we fix these things? Right? Yeah, that that was like an amazing impression for me. So then I immediately knew like, oh, OK, these projects are really amazing. Like they're being used so many places. They're solving so many problems and they have ideas that are evaluated there. Like they want to to hear about those and they also want me to fix them. Say innovation award, what kind

of project that you actually built back then? Yeah, That was a library management system for the Italian government. It was a very complicated, big project. So it starts from like the basic things like people need to loan a book and so, you know, you need to just record who was the person that took a certain book and it brings it home. But it was also like the central catalog for the national system. So if somebody wrote a new book, it needs to be assigned an ESBN code.

And there is a whole official process behind. And so, yeah, the complexity of the thing was, you know, much higher than what you would expect if somebody is not working that domain. So we had something like 1200 different database tables. And I remember, you know, statistics that I had to write for this paper for the award, like we had more than 2000 different web pages.

You know, this was all running at the time on Jboss application server, Hibernate, Hibernate Search, that was a key project from my career because Hibernate Search had just been pretty much created as a prototype by Emmanuel Bernard, who's a big friend of mine and became my mentor later. So it was like a prototype. He was doing some of the essential things which were like absolutely key for my project. Like we would not have succeeded in doing anything if Hybrid

Search had not existed there. But at the same time it was missing some things which are absolutely critical for us. So really for my project to succeed, it was essential for us when we were working on this library system that we implemented these missing features. And then of course at some point I promised them I know I would open source that components and push them to Hypernet Search.

So you mentioned you met some of your Java heroes, right? So can you? Yes. Who are some of your heroes? Oh, back then, yeah. I mean, I have lots of heroes today. So, yeah, when when I when I arrived at Orlando, I was very keen to meet some of them. I I remember. Yeah, Emmanuel, of course, was there. Bellaban, he was, he still is today, the leader of the Jacobs project. I think I met him there. I might confuse some events now. There was Andy Miller.

He was director for the performance team at JBOS. And one of the big problems we had with our system was of course, making sure that the system would perform at the level that the customer was expecting. It initially did not at all. We had made lots of mistakes and I had to learn really quickly again as a, you know, complete a junior person facing Java for the first time about profiling tools and hold what's behind that.

So when I get there and I see presentations from this person, which is giving me a lot of clarifications, a lot of really good hints, pretty much for free. Like these conferences are amazing. They're just, they're to just honest sharing of knowledge for just very, very good. So yeah, after that, I, I go back to Italy with a lot of new knowledge, a lot of new friends, a lot of network promises of contributions back. But I wasn't working for Red Hat, right?

I was working for these other companies and well, I realized

that I actually know a lot of things about Hibernate itself. And you know, all these things I'm doing with Hibernate Search, they needed to dive really deep and understand things more as a framework implemented and as a as a user. So I quickly started with a career in consulting. That was a good career acceleration.

I've been working in banks. I was like a lead architect for like a technology choices in one of the major Italian banks I worked at for, for Sourcesense, which was very cool, very small, very selective company in Italy about they wanted to have like the brightest minds in the open source ecosystem and you know, sell premium expertise as consultants.

I did that just a year. Like I, I started like very, very loving this group, but then I had to work often in a bank which they really valued us. But at the same time, this bank had the firewall and from within we could not use Internet, completely not allowed. And you know, they're big, very legacy, big systems complicated. They would come to me like I was a guru of these things and ask me questions that I needed to do

more research. And so, you know, you would need to do that at home and then research and then go back. So I also like disappeared from this network from the open source world because I was always firewalled out of the rest of the world. And the Hibernate team was missing me. Like they were like, oh son, where, where are you? And so I explained the situation and then they said, well, why don't you come work for us full

time? And so, you know, that was very interesting for for me, like, oh, I could join these people and work with them. And so I accepted that immediately. Yeah, since we're talking about

careers here, I did a big mistake there as well. I I was so keen to join them that they actually took a massive packet. And I thought, well, you know, it doesn't matter. I really want to, you know, I would work for three years. We'll, you know, we'll address that later. And it wasn't dressed later. Like I clearly, I mean, that put me very low in the ladder there. And then I realized I was a bit more senior than that. So it was fixed. But it has been fixed very

slowly over the years. Because of course, once you are inside a big company, there are all kinds of rules like I can't hear, just hear double your salary overnight today. Oh, we need to do this 5% here and 5% over there. So it took some time and yeah, thinking in retrospect, I probably, you know, they didn't have the budget at that moment. I probably could have said, well, let's talk in two months, you know, and that would have been better for everybody.

But yeah, I was so keen to join them and learn more and just work full time on those projects. But I I said, well, let's do that. And maybe that was a good thing. So I think one unique thing that

you just shared with us, right, you contributed to open source since very early in your career, right? Since you know, maybe you won the award and you got into Hibernate, Hibernate Search, maybe you kind of Ditto a bit to

like banks and all that. But you have always been contributing in the open source, which I find maybe for some people it's rare because they think you might need experience, understand a little bit of fundamentals and technical details before you can contribute to open source. So maybe can you share a little bit back then? Do you find it challenging as a youngster, you know, contributing to a big open source, you know, like Hibernate and all that? Or do you actually find it's

actually useful for your career? Oh, it definitely was useful for my career and it was challenging, but it wasn't that early in my career to premise like I had been studying a university degree, which is in Italy. It's like it's called like the old system. So university degrees were far longer, so they would go much deeper and I was busy with that. So it was a kind of advanced

course, right? So many of the fundamentals were kind of note to me. Java, I was not a professional in the Java space, of course, because universities, they don't really teach you the practical ways of things like, so for example, making a library, that's something that I would have never seen. And I think it was a library like something that on the side. So that was new to me or like a build systems, right? You would not really use those

in like university systems. But I, since I was working also the in source science and in this other contractor positions, I had been exposed also to agile practitioners, extreme programming practitioners and participated in these communities. And I had some really good mentors as well helped me. So I was becoming really quickly familiar with these projects and then and only then this open source things happened. Right.

If I look back at my career back then, actually Hibernate was kind of like released early in my career. To me back then, it was like a revelation. You know, usually we wrote like, I don't know, like JDBC driver, plain sequel, then come ibatis, Mybatis, right? And then Hibernate came, became like the de facto ORM. So to me, that was like magical, right? Oh, what do you mean? You can write just plain simple Java object and you can translate to SQL queries just by

itself. I mean, back then it was like magical, right? So having been in that project for that long, right, What is the state of this Hibernate project now? Is ORM widely adopted? Is it like the standard practice for Java developers these days? So tell us maybe a little bit more insight. So it's a great question. We do have download statistics and it's doing incredibly well. Like we are in the dozens of

millions of downloads per month. Problem is we don't know what people do with it. So for all I know, it might be 1 script somewhere that's Downing it a million times per day. Good here in practice we do know of course via read that we have customers that we know they're using it because they open support tickets, they ask questions, they ask clarifications, they ask for like road map plans, they suggest features. So we know there is a, a lot of

activity there. We are not the first line of support, but there are like 3 lines. So there is lots of people answering, you know the the most common questions they they don't want to bother us. And there is a second line of people more expert for the more difficult questions. And only the maximum escalation level comes to our team direct, right? So even there, we struggle getting a bit of feedback from the front, let's say, but just looking at the sizes and it

starts there. We do know it's heavily used, right? And then there are community report researchers that try to get a bit of a breakdown of what community happening from those. It seems that the S Hibernate is very widely used and it has an extremely large market share noise. They're always a bit biased. You know, each of these vendors, they ask their community, their section. So it's a bit difficult to have the full picture or even like what's the error range in this

measurements. But we're very confident that's pretty much every Java developer has heard of it, you know, or used it at least once in some projects.

I guess that also depends because back then, right, I must admit I have left Java world for, I don't know, maybe 10 years or maybe around that time by now, right? So back then, like Spring Boot was the kind of like the main framework for us to build any kind of application. It could be recipe and micro service, whatever that is, right? And Spring Boot by default package Hibernate as their GPA of choice or something like

that, right? Maybe that could also be the driver for, you know, the number of downloads because every time you build Spring Boot apps it downloads those kind of stuff. Yeah, we like Spring. The the Spring group is a bit of a competition to Jboss and Red dot, but they're also like big friends in the way that you know the they understand that Spring wouldn't be as useful without Hibernate and we totally understand that Hibernate wouldn't be as popular without

Spring, right. So there is very respectful back channel communications between them. I am a little bit sad that sometimes by how they advertise some things. And one problem that we have in the relation is that like we are allowed, it's even in our employment contract, we are allowed to contribute to any open source project ever when we want to. We don't have to ask for permission. It's clarified like this in the contract. It doesn't matter which project it is.

It can even be a competitors project. Other engineers are not that fortunate. We we understand that. So there there is a bit of this sad thing that I know the Spring team sometimes would like us to make some changes. And it's always a bit of a difficult conversation because they can send patches. It's not allowed for them. And then, you know, for us, it's a bit tricky to understand what exactly you mean.

And some members of the Hibernate team, they really struggle with that kind of relation. And therefore, you know, sometimes there is a bit of tension there. But yeah, overall, I think there is a strong sense of mutual respect. And of course there is Quarkus, which is a challenger to string boot. That makes things even more

interesting. I was in the initial group that's created Quarkus. And so actually one of the things we were using as a like a key thing like can this whole technology work was like the proof was like, can you get Hibernate to work in this very special way that's Quarkus does? The idea was like we wanted to have Grau VM to support Grau VM properly. Gravel VM at the time had a lot of limitations. Many of those have been, you know softened or resolved nowadays.

But at the time the list of limitations was really daunting. And among them pretty much in this list of limitations Hibernate would do all of them. So I was tasked we can you try to make Hibernate work on Gravel VM. And my mentors, Jason Green and Emmanuel, they were very keen about you need to make it happen. It's really important for the entire Java world, the entire Java ecosystem, and I'll get back to that, why we thought

that was the case. So they were saying to me, OK, maybe some of the features of Hibernate cannot work in native, remove them like they were thinking or suggesting to me create something new which would like have the role of Hibernate in this new world but may be different. And we were like what about like JPA the spec right and things.

Now. The situation was a bit dire like so we do have, we give a lot of importance to the spec, but at the same time the way cloud native development was going, it was clear that the way the direction Java was taking was just not compatible with this new feature. And so there was a bit of a strong concern that the Java would still be alive in 10 years.

And then we were really thinking that, OK, if the current Java enterprise specs are not fit for the purpose, maybe we should propose a new set of specifications. So my task initially was actually like write down what you would think should be something that we were calling like JPL Light. That was the idea. And you have to identify which things that Hibernate is doing today we can do in this JPA light and which things you need to leave behind in interest of making things happen in the, in

the Gallian world. So I start working on that. And this list is very long and the amount of complexities we have, it is very daunting. You know, I'm thinking I'm showering a lot and going back and, and at some point I have this, you reckon moment, which was really like a brilliant, like I, I just twist around the thing a little bit. And then I, I wrote this e-mail to my colleagues saying, look, if we boot the entire framework in this particular way, I have

no limitation whatsoever. Like we, we solve all the problems that Grav VM is offering. And so there is no need for any specification, right? So that was a very nice breakthrough. Of course, this was all theory. And then, you know, we start prototyping those things and well, these prototypes are all in GitHub. And so people can have a look now. It's pretty much if you check

out the work with source codes. And you sort them by date and you go in the very early things, you'll see some scripts and scribbles and really terrible code that I wrote at a time, which have nothing to do with what resist today. Well, there were other colleagues working on other aspects to make a new generation framework, but I was focusing on this thing of like, do we need a new spec? Is GPA fit for the future in the the gravel VM space?

Right. And that was resolved this way, but it the way I was resolving this was extremely specific for Hibernate. I mean, this was a good breakthrough because if we had solved these workarounds for Hibernate which had all of these limitations, then it was probably going to be easy to apply the same ideas to all the other frameworks which have simpler use of the JVM strategy.

Maybe for the benefit of some of us which don't know the details in like what are some of the biggest limitations that you see Gravel VM is not able to run Hibernate or maybe most of the Java frameworks back then. What are some of the biggest hurdles for you and how did you actually solve that by inventing walkers? OK, well, I wasn't alone in inventing Quackos, right? I was focusing from this aspect. Yeah, for example, Gravel VM, the entire code base needs to be

known at build time. That means also like that the bytecode is not changing. So no bytecode manipulation, no generation of bytecode at runtime. And also like no reflective invocations either. It needs to do reflective calls now since many years already we tried to not use reflection on runtime because it used to be quite inefficient in the JVM. It's better optimized nowadays in the JVM, but still we try to avoid it. I mean we already implemented the all the schemes to avoid it,

so it's better that way. But at least during the bootstrap, we need to know your entity, which properties they have, what's their name, what's their type, and which classes actually have under certain annotations, right? So all of that goes pretty much via the JDK standard reflection API, at least it used to. And the reflection doesn't work at all in ATV unless you specifically tell the compiler, hey sorry, there is like an additional resource file that you can type in in if it's Jason.

Now I forgot I I haven't written one of these resource files in years. But you can give a lot of input to the diagram compiler to tell it oh at runtime. This method might need to have like a reflective access. This type needs to have a reflective construction. This other type might need to be serializable. You need to be thorough in listing all the cases otherwise

it's going to fail. Resource loading wouldn't work unless you register IT. Service loading doesn't work unless you register the type that's going to be loaded. And well, we do all of these things in Hibernate and in many other frameworks, right? Yeah. Now the key was really like the Gaussian compiler is a Java process and it is triggering initialization of the constants

in your code. So what I did was really like, oh, it means that if I with my main class and I do like public static final session factory and I initialize Hibernate in a constant, the LVM compiler is going to initialize the entire Hibernate in this constant. And it did. So it's booted entire Hibernate in there. And now there are some problems with that. First off, you don't want it to actually connect to the database because you're building the application.

Your database is maybe not even reachable from this environment. Or well, you certainly don't want it to connect even if it's reachable, right? Because you're building. So yeah, I started patching Hibernate in a bit of a private branch, you know, we want to do real quick, like what happens if I delete this stuff and nobody cares?

So lots of patches in there. So I just make sure that the life cycle of the booting phase is pretty much split between two phases, building the entire model, discovering, doing the reflection work and all that. And then actually, you know, connecting to the database and doing the fix. This was complicated because the boot strap is very cyclic, very unstructured. It's, well, it is structured, but it's designed in an era in which this separation was not an

objective at all. Now the trick here is that all of these reflection and all of these work in annotation, scanning and configuration parsing and all of it. It's happening when the compiler is running. Now the compiler happens to be a valid JVM. Grove VM is written in Java. So this processing which is running and defining the constants, all these operations that are not valid after being compiled are valid during the compilation. So all of these limitations,

suddenly we're not applying. I just needed to make sure that we would not use any of those things at runtime. Of course we would still use some of those things at runtime, but it's really reduced the set to something that was manageable short time. For example, Hibernate, if you use bytecode enhancement on entities, it will not need a reflective call on objects except the constructor, I believe. But still, I guess.

But if you do the bytecode, you know, if you don't do bytecode enhancement, then a lot of reflection is happening. So, you know, very quickly we decided, well, bytecode enhancement is mandatory. We don't even ask people to use it. It's just something the framework does for you during the build.

So it's it's simpler and it's also simpler for us because one problem Hibernate had over the years is lots of configuration properties, lots of even in the engine possibilities like do we need to handle the entity as a manager? Do we need to handle, Has it been enhanced with which capabilities? And so for us, even like reducing the things that we actually need to support also helps us to increase the quality of the. Current, right, I think 1 aspect about Java back then, right?

It used to be very people associated as a heavyweight, you know, whenever you run Java applications. Plus, yeah, when you boot it takes a while, maybe seconds and it depends on your project. If it gets bigger then it might take even up to a minute I would say. Now with all these inventions like Quarkus and maybe Grau VM itself and maybe other projects that I'm not aware of, has Java become a valid choice for like cloud native application?

Think of it like a function as a service, you know where you need to boot up really fast and react to certain events. Has it reached that stage yet? I think it did, yes. It's absolutely in that category. Like we do have a Quark Goes version for serverless. It starts in milliseconds, so people can really decide if they want to go into that direction. Actually, the beauty of it is that you don't have to decide in which direction you're going

upfront. You're not going to choose a framework because you're going serverless. You're building your code and then you can deploy the same application easily. You can change it to in ordering the in the build property saying, well, I want to build this as a serverless function, right? And then maybe you realize, you know with the the load on this serverless thing is getting higher and higher. You're better off if this was like a regular Java application.

It's just a matter of changing the configuration property of the system. Or maybe you want, you know, you are getting like very low load occasionally, but it's more convenient for you to run it as a native image and you just can't compile the same application to native. What I really like is this flexibility that you don't have to decide upfront, like you're not going to use Quarkus because you need native. You're going to use Quarkus because you want to write in Java.

And what's coming after that, well, depends on the needs of the day. And you know, requirements change often and agility is quite important nowadays. Helps to keep the cost low to adapt really quickly.

Right. I mean, Quacus itself solves almost kind of like similar problem to Spring Boot, right? Like it helps people to bootstrap like create new applications faster. And there are a lot of, you know, niceties, you know, other generation and things like that, I guess. So tell us why we should use probably Quacus versus Spring Boot. And I know that for some people this is probably common

question. So I think we are at the stage in which the majority of German workers have experience with Spring Boot. So one thing that we really took a lot of care of is to make it really easy for somebody that's has experience with Spring Boot to move to Quarcos. There is a book by Eric Tandrea about it's called I believe Quarcos for Spring developers. And the book is free.

You can just Google it. You can download the PDF for free like or you can also buy a paper copy if you want it sent. But essentially you can get the PDF for free. It is really easy because you know, they're built on very similar technologies like if you have say a very large complex hybrid model, I mean, they're running the same hybrid and they're probably running the same version of hybrid, right?

So, right, that's a piece of cake right Now there are some AP is in Spring. Say you're using a Spring Data JPI, right? I don't like it, but that's personal, right? It's my totally be fitting for your project. Now we do have a Spring Data JPI in corpus. It's probably not perfect because when you're replacing implementation from A to B, there might be some imperfection, but it will definitely help people to migrate from one to the other.

And basically they're built on the same, similar standards like. So if you're using like the JPA spec or even if you're just using JDBC Servlets, JAXA, RES, you're using JAXA, you want to, you know, use Kafka Connect, Elastic Search, it will be all be pretty very, very, very similar, much pretty much the same in many cases, same code. So that's very easy. Now, why would you use Quarkus? So there are lots of very good reasons. First off is, well, the developer Joy is fantastic.

Developer Joy is for our framework of reference, but it means several things like that. Pretty much. We make your productivity very high. The feedback loop is really short and that makes people happy. Essentially the main feature is the life reloading capability. We do aim at any change making the code when you are in dev mode is reflected in your running system 100 and 100 milliseconds.

That means that you're, you change a method, you refresh your browser and you immediately see if you're on the right path. You made a mistake like I did a demo this morning and I forgot to change some path if in the rest endpoint and you know, then I had a duplicated path because I made my change by copying a block and then making a change. And then, you know, I refresh the browser, I get an error in the browser saying me what I had

done wrong. OK, so I flip back to focus, change the thing, refresh and now I'm fine. These kind of errors since I get immediate feedback and I'm still focused on. I just created the method. It's creates a much lower cognitive load, right? So I'm not frustrated because an error happened because I'm still in the flow. I have not been distracted. And then I know I just keep going with my things.

So I'm happy because I'm very productive and I'm learning and I'm constantly getting feedback that I'm on the right path. Speaking of feedback on the right path, we have something called continuous testing. So while you're working, you can have continuous testing running, which is pretty much like it's running the unit tests loop really quickly. And while you're coding, you might see, but now this test is red. This is immediate, right?

And there are some interesting techniques in there so that it actually knows how to prioritize which test to run, which are related to the code you modified, right? The other thing is dev services. So if you want to start developing say a new application, which is like Hibernate connected to Postgres and maybe elastic searches in Hibernate Search and maybe finished band as an external cache. Now you start having many

external components. Now as a developer, it quickly, you know, becomes, oh, OK, I'll spend my morning installing all these systems in quad Cos you don't have to install anything about your starting. It knows, OK, you have the Postgres extension, you have Hibernate. This implies you're going to need Postgres. So it will behind the scenes, it will use those containers, fetch Postgres instance, start a Postgres instance behind the

scenes for you. And you don't even have to provide the connection properties because those are being provided and injected into the running dev mode. So you can quickly start working on your model and immediately get refresh. You know, you just refresh the application and see the schema evolving as you're evolving the model. Or you know, in the other direction with depending what's your cup of tea. But the flow goes really fast and you you're not wasting time.

Boring things, weren't it? I, I really believe that the feedback loop, right, the shorter you can make it right? And the developer joy, right? I still remember back then when I did Java, right, whenever there's a class signature that I need to change, it was like, oh man, I have to restart my applications, wait for the booster.

And back then, when there was AJ Rebel, maybe you have heard about it, that was also quite revolutionary, although it was quite pricey back then for some of us, right? But yeah, this thing that you mentioned, even though I haven't used Quarkus, I really believe that it can make life really simpler and more productive for developers.

Yeah, yeah, we, I remember at the time, yeah, Jerebel was very interesting, but I think they had a big maintenance problem because they had to know how each framework is going to react. I needed to know how to, I remember the conversation with them. I was already known in the Hibernate community. They wanted us to have some kind of stable API that we would promise to never change over time so that they would know where to hook. It was very useful, but it was

also extremely costly. You know, you know, Quark was really takes a very innovative idea there, which is like since it's so fast to boot, just reboot entire application over time and it's very reassuring. It means you really have a clean slate and this is really the output. It's not, you know, it's something fancy because maybe some of your tools is something strange. But the state might be gone right if.

You the state is gone, but that encourages you to also work on your import scripts and your setup scripts in the in the right way, right? So you're constantly also checking that those things are In Sync. It actually leads you into the right touch.

So all along in your so-called career, right, maybe you dealt mainly with Java technologies. I know like for some, I don't know, youngsters, right, People who just came into software engineering, maybe in the last 10 years or so, Java is associated with like, oh, legacy heavyweight and now also like

the version changes so fast. So how do you compare, maybe from your point of view, maybe a little bit biased, but how do you compare Java now with like modern technology, like programming languages, like maybe Rascal and even TypeScript, right, Python. What are still some of the strengths that Java has that people should consider? Even though they're like youngsters, They want modern technologies, Yeah. I honestly think Java is in a very very good position. People maybe don't realize it

right? Because you know, depends who you listen and what you get excited about. But if you look at, you know, each of the languages you mentioned, they all have like 1 strong suit and very weak in other areas. While Java is maybe not top leader in all of those areas, but it's very close to be leading in all of those areas. It has been innovating quite

aggressively recently. Like I think the Oracle Stewarts and including like the Reddit engineers also contributed some the improvements there are are studying up the pace accelerated and it's very interesting where it's headed. Like now we're working on a project Leiden. There are lots of interesting things happening in the open GDK, but personally very interested in Project Leiden because of the things that we do with Quark Quiz and how we also

integrate with it, right. So project Leiden is going to, you know, they kind of realize from pressure and low VM interesting people that it boots faster that the open JDK had the problem in booting too slowly and they're addressing that. It's improving very significantly with Leiden. And so that's very interesting. Project Lily put is making it consume less memory because it had this fame of being bloated

and all that. Honestly, the fame of being bloated is very often coming from the frameworks that were pretty much not designed to do things to boot fast because nobody cared. The application was going to be up for many, many months, and if it was taking some seconds more when it would booting that was like a drop in the bucket and completely meaningless. So these things are being addressed now because people start to pay attention to them.

Now, of course, these these libraries, they're so widely used and they're so large and feature full that it takes some time to get there right. But we are getting there really quickly. If you look into the Quark space, like a very big complex Quarkus application with thousand hybrid of entities can boot it under one second. Wow, that's that's yeah, that's I'm very, very happy with that.

But we keep working on it. I have more ambitious targets like we want to go in there like 203 hundred milliseconds of space. And yeah, about other the other languages. Well, Rust is really very interesting, but more for the properties that it has, right? We do believe that in terms of like achieving maximum performance or maximum efficiency of the system, like if you really want to handle a very, very high load, Java is the way to go. It's came really.

There are so many clever things happening in the JVM in Grove VM. The combination of these things, the combination with quarkless things that we're exploring are really pushing the throughputs to very, very high levels. And we do compete and we do benchmark ourselves also with benchmarks in other languages, because work is significantly faster than any other Java framework around there. So it's not fun. The challenge really is like, is this design perfect? Like can this go any faster

today? To verify that I need to compare myself with other languages including like Rust, assembly, C We're getting really close to that level. How about Kotlin? I mean is it like the default language use or people still write in Java? I see a lot of interest in Kotlin, but again, it depends on which area you're looking. I have not intentionally avoid Kotlin. I tried to learn it but I never had any actual need. I I'm not a Kotlin professional

at all. Everything I do is in Java and I don't feel the need for Kotlin. I don't know, time might tell, but the impression really is that Kotlin and Ceylon, they have been pushing the JVM to innovate, but many of the most important things, they are now available in the JVM or they are coming very soon in the JVM, right. So this is kind of removing the need for people to go and earn Scala cutling things, yeah. So let's maybe go back to the

Hibernate side, right? So ORM technologies, I mean, many programming languages now support some kind of ORM libraries. Some people like it because maybe they can write some, you know, database related applications fast. Some people really hate it. So from someone who is like a common dinner of Hibernate, what is your opinion? Yeah, we we had to have a thick skin because yeah, there, there are lots of Hibernate haters, right. And there are two categories I

think of Hibernate haters. Generally there is a large group of people that sadly have been both Hibernate the wrong way and I am trying to address that. It's difficult because knowledge propagates online without getting, you know, I'd have no control of those things, right? We, we might have some authority say, hey, I work on Hibernate, but still, if somebody publishes a book and it's completely wrong, I, I can't go to the editor and say, you have to withdraw this from the market,

right? And somebody purchased a blog, I can't go to Google and say, you need to delist this because I don't agree with its content, right? That's not how it works. And then of course, there is a category of people that they have been imposed that you use, you have to use Hibernate for these projects when it made no sense, right? This is something that we also fight for. Hibernate is not something that should be used in every situation.

There are some situations in which is really under the right tool, but still it gets imposed as a standard by in some places, right? And of course, if you are a smart developer and you understand that this is being imposed to you and it is the wrong tool, you know you're not going to have a good relation with the tool. When do you think it's not the right time to use like ORM or Hibernate? Well, I might be biased. I would always start from an ORAM, or at least in most cases.

Of course, if you need to do a lot of operations inside a database, maybe store procedures frowned upon, but in some cases they are the right. I would always try to minimize the the span of transactions. So if that implies that the transaction gets extremely chatty over a wire that's a problem, then it's not a good solution. But in most cases, I would have in my system, I would have

Hibernate available. And then, you know, there are many operations, many business operations, and some of them would use Hibernate, some of them would not use Hibernate. But it's important that people remember that Hibernate is an ORAM, but it's also facilitating access to native SQL queries in many ways and mapping results of native SQL queries.

One thing that was done recently, Hibernate had since a very long time that had the stateless session, which is important for some of these access patterns. And well, recently the state of the session got to learn some more love like some some more improvements in that area and the documentation was improved a lot as well. So a good user should understand when to use hybrid with the stateful session, hybrid with the stateless session, or when to just send these settings to the database.

I guess this also comes back to the design, right? The design of your application, because it can be misused in a way such that your entity class is used all over the places, right? Maybe from the entry points of the APIs you deal with the entity class straight away, right? You propagate all this, you know, so-called object chain all over the places and somehow

magically the transaction works. I guess that's when people actually kind of like hate this ORM and especially if you have like the n + 1 problem, those kind of stuff, right? It tends to be very slow. I guess the design is important, right? So you encapsulate the entity for the right reason and don't propagate it all over the places, don't expose attributes that you're not supposed to to other parts of the, you know, other modules, I guess.

So maybe in your point of view, what kind of design pattern maybe that people should think about? Is it like the main driven design or is it like something like the hexagonal pattern? Is there anything that you think from your experience as well? Those patterns, they're all fine, right? It's more like how people think that the operation will work in a database that is important.

And then then there are lots of like Lord people give each other which are actually unfounded, just a very simple one. A lot of people still believe that an Hibernate entity needs to implement Serializable. It's just not true. It might need Serializable because you're using that same object with other frameworks which require it, but Hibernate doesn't care at all if it's serializable.

We never need that. And then, you know, they are serializable and then they add the serial, your ID and you know, they're adding lots of things in there, which I'm thinking, well, fine, you can add it, but you're just, you know, making your code less readable. And then, you know, there are discussions, getters and sectors rather than a field. Make it public. You can do whatever is good for design your application. I mean, it doesn't care. It can be a public field for all

we want. It can be a private field. It doesn't matter. We'll we'll get access to it in some way, right? And it doesn't really make any change in the semantics of of what we do. It's all the same. The equals and hashcode is a very tricky one because people seem to think they have to implement equals and hashcode on the entities. In practice they don't. But if you implement it, there is a very good chance you're getting it wrong. So I would typically suggest that implement it please.

And why do I say you're getting it wrong? Because it's an entity. Purpose of the entity is that you change its state to represent changes that you want to happen in the database. It means that you're changing the state like you're going to change the hash code. Now, the only reason for you to implement equals in hash code is because you want to store this, say, in a hash set somewhere. Again, Hibernate doesn't care about this, won't it? If you implement it or not, it's totally fine.

But you might want to implement something in your entity because you need it for some other reason. Like you want to store this in a hash set. But if you store things with multiple attributes in a hash set, you're calling for trouble because that's how Java collections work. So it's a bad idea for Java collections. The only thing that's typically stable in an entity is the primary key.

And I'm saying typically because if you just created the object and you didn't store it yet, the primary key is not assigned unless you assign them yourself. So one correct way in my opinion, because of course might vary, but in my opinion, 1 correct way of implementing equals and hash code is to only include ID, the primary key in your implementation. But also to make sure that before you ever invoke those, the ID gets assigned right, either by you or by the

framework. And then you start having these kind of responsibilities and you know, if you just leave the default, it's going to work. Now that you mentioned it, I could still remember back then, right? Equals hash code, we use ID auto generation, most of that. I haven't choose the important properties or attributes. Everything would be, you know, important for the entity class.

So going back to the open source world, right, You mentioned you work in open source, but also get contracts like employed as in like you contribute to open source for some people, like for me, I haven't done it before. How does it like to work in an open source? But it's kind of like paid. To do that. So at the time, you mean? Yeah, before I was employed by Red. Yeah, yeah, Yeah, that was, that was very interesting.

Of course, good money, but also you spend some time in the commercial aspect, things which I hated, but I would forget to send invoices and then just thought I'd care about it and then I would have no money. But you know, if you do it properly and you are disciplined with the commercial part, I think that would be a very good career, right. But you need a network, right. You need to be somebody that's

actually an expert, right? So to be an actual expert, you need to spend time contributing those things. So I think a model that would work really well for an open source contractor is somebody that charges a premium because so to some important customer, because he's actually an expert, but also because he makes changes happen in open source

project, right? So the company might have a particular issue, you are able to fix it and therefore you can charge a premium, but then you also actually do fix it and make sure that it gets merged. Now that is a bit tricky because you know, you might think, well this is a solution going to push it to the project and I'm done that you charge, right. But there are the other members of the team might not agree with that change. So there is that risk.

It means you nearly need to work or being pretty good, right? Because you need to be persuasive to the other people and you need to really make sure that it's a high standard good quality work, right? So yeah, you might charge a premium, but maybe you have been at a company just two days, but you're going to spend 20 days making sure that that budget gets. So please stop balance.

So at the moment, I mean if you're still active in the Hibernate, because you are a technical lead, right, I assume, how many contributors are there in this project? I actually do know now because we just changed the license of hibernator M, It has been since forever LGPL 2.1 with what we

call crosspot clarification. Now in Java, LGPL spare you the details, but we decided at some point that it was, you know, rather than having to have clarifications about what was interpretation of the license to reassure people that it's fine, it's open source, but it does not affect your code. That was the concern for some companies. Of course, not many companies because a lot of people use it, but we did have some cases in which people have this rule.

You can't use Hibernate or you need to use. You can use it, but the code needs to be compiled purely against the JPIAPI is that you can't invoke Hibernate code to clarify that it's easier to be Apache licensed by Apache licensed version too. So we wanted to change to Apache license version 2. This is actually one of the first things I asked my colleagues when I joined many, many years ago is wouldn't it be easier if we switched the

license? I remember they laughed at me like, Oh yeah, maybe, but it's impossible. We can't do it and why, why can't you do it? Well, you need permission for contributors. So now I really want to change the license because of all the reasons we can get them later. But we had to contact every single contributor ever that made some meaningful contribution to the project. Key is meaningful, right? Because otherwise we would never have finished.

But yeah, we had to go through it's like more than 2000 contributors. So we start sending requests to the ones that contributed the most so that we didn't have to review as much code. And then there is this long tail of people that contributed maybe just one or two patches and those who have been looking at 1 by 1 to see is this meaningful from a legal link, copyright, intellectual property law point

of view. So you discard some of them and then you start sending more emails and more emails and more emails. And you know, eventually we got permission from everybody. So now it's partially licensed too. But that was that was big. It's a very large community. That's pretty a lot, right?

2000 plus contributors And when you say meaningful, what do you mean? Like how do you define meaningful right? Yeah, the the tricky part was to understand that it's meaningful in the context of intellectual property and not from the point of view of software engineering. So if you had for example, in the grammar, there is a piece called this is like a string. It looks like a bit like a regular expression. So imagine you have a regular expression that's like page long.

Somebody added question mark. It's a very specific point to fix an issue. You as a software engineer, you look at that and well, you know, it's A1 character change. At the same time, you know, it has probably hasn't been easy, you know, to figure out that from the problem you had distillate to a test and then eventually figure out that that one character was missing precisely that point.

So a lot of work behind that patch, but from an intellectual property point of view, it's just one character, doesn't matter. On the other hand, if somebody would fix something trivial, just a one liner in implementation. But now a rule we have is every contribution needs to be covered by a test of Congress for that for future regressions so that you can say if it's fixed then

it will never happen again. So even if somebody would contribute a fix, which is one line would ask, well, you had a test for it and now the test would have an entity. The entity needs to have a name. So somebody would just have a person. Somebody would say animal, somebody would come up with something new. There's creativity in that that is meaningful.

Wow. Even if it's a very trivial test, which is probably copied like the the same template and the same pattern for many, many other things. So you need to understand this difference.

When you mention about that, I mean, it reminded me with all this AI now, right? Because somebody could generate tests very easily with AI and now this becomes blurry, right? Is it meaningful because, you know, a machine actually generated that? Like in your maybe open source experience, have you seen a lot of increased contributors that actually leverage AI? And what are the reactions of the core open source community towards, you know, AI?

Because on one hand, sometimes it works, right? But most of the time also the design might not be optimal and maybe italicinates a little bit. Or is it fringe some copyright from some other libraries that it copies, like you don't know from where? So how do you? What's your take about all these? It's very difficult to say if somebody use the eye, yeah.

So we do see an increase in contributions, but I mean, Quarkus didn't exist six years ago and we have 1000 contributors in Quarkus nowadays. So it's really skyrocketing the interest, but also the amount of contributions in there, it's growing significantly. I wouldn't know if it's AI, right? I would guess there is very, very little AI there. There might be some, but I, I suspect actually normally that's

my suspicion, right. But if I need to create a bash script, which is say copying some things from one to the other, I've seen that AI is very helpful with that because I'm a little bit out of my territory. I know how to write mesh scripts, but I don't remember some of the details. So I need to like how is the equality sign again for variables, integers, I don't remember those things. So I use an AI for that. It helps me.

I can check, Oh yeah, that's what I needed to services some memories and you try it out, works. But when it comes to Java code, it never did the right thing. Never. And I think it's because the kind of work we do is always kind of novel in a particular strange space, right? I'm not using Hibernate or creating a new entity, which would potentially be a very repetitive thing that requires maybe domain knowledge, right?

Maybe you are in a medical field, you know exactly what kind of proteins you need to do here and therefore you you map that and putting the annotation on there and the properties is a boring thing that I can help you with. The kind of puzzles we solve are a bit of a different league.

So you have worked with so many contributors, maybe tell us what are your biggest challenges working in such a big, you know, open source project? There was a time in which I tried to follow all the discussions. I no longer do that. It's, it's important to have subgroups and a lot of trust in the other people. So I know there are areas that are being watched by the colleagues, friends, external contributors that I trust and I

really, really trust them. I also know that if they needed me, they would come to me. And so I don't have to go and read. That has been overwhelming. That does work. I'm quite curious, is there such

thing as politics in open source project? Because as you have numbers of people right, maybe some people have a strong opinions, they gather influence. Is there such a thing? Because I've never been involved in such a big open source project. I'm just wondering because this has to happen in any kind of big organizations. I think there is. I wouldn't say if it's politics, but there certainly are strong opinions. Very often they come from

misunderstandings. But also, you know, some discussions are happening in a chat maybe, and you are typing a response before having read the other one. People start interleaving things. They go on a tangent, right? And then there is a significant misunderstanding sometimes. And now if I, if you didn't understand the problem and then I'm really sure that this is the solution and the other person is like, you're an idiot, then that that doesn't solve my problem at all, right?

So, yeah, these things, these things happen. I've never seen people being intentionally going in the wrong, you know, or trying to mislead others. Like everybody's coming in very good faith, right? And so when there is something, some tension growing, it's always a misunderstanding. But also, you know, emotions, though, they don't come across really well in written form. Also, it's also for engineers, they might have a bit of empathy problems. And it's extremely

international. So culturally, the expressions might not translate really well or translate in a wrong way. And then you know that amplifies some problems. Right. So, yeah, I think I'm always amazed, you know, like in open source project, especially with this many contributors, people may not meet each other, right? They may not know each other, but they can build like such a good software, you know, like that works and serves more people than just the contributors themselves, right?

It's always amazing for me and kind of like the pickup rate of open source maybe in the past 20 years has been a lot, right? Like so many companies these days will just adopt open source. Before when I started my career, it's always a problem, OK, you cannot use this open source. You have to go through, I don't know, an enterprise architect board to approve a certain version of open source.

But these days, I'm sure like almost all software engineers, we'll just use open source because it's so big with this and so made life so much easier, right?

So one aspect of open source that is becoming a challenge these days about security. We have seen many threat actor trying to be a contributor, make some changes that actually is, you know, security threat. How do you actually identify this detect and maybe protect your open source from such, you know, threat actor? Yeah, that was certainly a wake up call. We used to give say commit

access quite easily. Yeah, I wouldn't say too easily, but if you had been around for let's say six months and done some good work, I would give you commit access nowadays. I am, I'm not saying I'm going to do a background check, but kind of like I want to know what kind of person dealing with and the whole, the whole life cycle and management of projects changed a bit. Like in some projects, we really just really restrict the permissions to the bare minimum.

This might seem a bit unfair and we're trying to compensate the fairness now with, you know, a bit of an open governance that is great writing down rules of like, how do you join the project and what are the expectations? It's not clearly written down, right? So that there is a level of fairness. It's difficult to write down those rules because you we need to think about them. How, how does this work, right? And it's kind of a novel territory there.

But yeah, there there was a time in which it would have been fairly easy to get commit access. But even then we always review each other's codes. So the way you know, GitHub rules are set up, CIA set up, and we really do expect that even if I may want to make a change, like I said, the request tell somebody else is going to review it and then it gets merged. And there is a lot of automation there.

Some of my colleagues so they created a very nice framework to create a GitHub bots so. Any time there is a need of making changes there, there is new strip thingy starting and helping. So it's kind of easy to also enforce roles like this. Also with git, when I start my work I fetch changes with look at them. I might miss something for it. Yeah, that's the risk.

So, yeah, again, like these security issues really is very hard and especially we have heard so many, especially maybe in the JavaScript world, because when you pull package, you pull maybe 10 or more dependencies. Sometimes it's just a small library that you think it's insignificant, but it could be, you know, changed by some hackers or whatever that is such that you're using vulnerable libraries, right? So I think, again, open source can be a threat sometimes,

especially these days. And I was having chat in some of the episodes as well. Like when you create an application, 90% of what you're running. It's. Actually open source software. So yeah, like you really don't know how come the code gets generated that way, right? What kind of things that it does on the background. So I think, yeah, maybe one challenge there for people to actually also identify vulnerabilities as you pull new versions or new changes in the.

In the yeah, well we're certainly looking at it much more carefully. Like one thing we're working on now is like a reproducible bills. We want to make sure that the bills are reproducible. That helps, you know certify origin of things. It's going to be mandatory for red dot products and projects. I believe it is already maybe sorry not very involved in those areas, but there are certainly a lot of attention, right.

For example, anything like you know, Red dot supports product versions of our projects and that's why they employ us. They sponsor the project pretty much, right. But what they do is like they do rebuild the entire thing in a closed adapt environment before it's being sent to customers and they have a lot of additional checks and controls at that

level. Of course, that happens after our upstream work. So some things that we would like to do really is to improve the upstream project as well. It's not just responsibility of red dot, it's a responsibility of how the open source project is set up. And well, one of the things we're doing now is we're actually donating the entire Hibernate code base and intellectual property to an open source format. This is literally to signal that this is not just red dots

responsibility, right? We do have many contributors from other companies, especially like database vendors. They really like that Hibernate supports all their exotic features, including features of database versions that have not been released yet. Initially those conversations were a bit funny and like they wanted to pay us to implement things that we weren't allowed to know about unless we signed

an NDA. And but we're not going to sign an NDA with like Oracle or things like that when we're employed forever. And it gets all very tricky. So they all these other companies, they do stuff people that work with us on fiber code base. And we really want to make sure that that happens more frequently. It's really nice for us and for projects to have more companies involved in projects.

So for that, these projects are being donated to a common house foundation, which is a very young new foundation. We did explore like the Eclipse Foundation, the Abashi Foundation. They're all fine and great for some projects, particular projects. But for a mature framework or mature library like Hibernate, in which we already have our way of working our CIS, our system being by getting in the Apache would have been problematic.

You need to migrate our ticket system, our mailing list, and it's a lot of work. They also have a lot of other rules that we don't necessarily like. We have an established process which we think works fairly well, like we have experience as well. So common house gives us a bit more flexibility in that sense. So yes, going to common house and yeah, we really hope that that's triggers them more companies to not only contribute but also steal it and lead it. This is all entirely in hands of

Red Hat engineers nowadays. Just totally fine. But, you know, more diversity there would be really nice.

So if you are allowed right to talk about, so you've been in Red Hat for like 16 years and throughout this time there's so many changes, series of acquisition, series of license, probably changes for some of those. So tell us how Red Hat you know is going to advance in the next few years, right? Where do you see the next big thing that would come from? Red Hat? We just had very big news. It's very big for us, probably hope meaningless for everybody else, but our entire group is

being moved to IBM. So we will no longer be under red ads, but under IBM. The things they promised was the reasons they gave us seem very positive, like it seems like a really good idea. IBM has always had a very large team working on a lot of Java things, including a lot of open source Java projects. And so we're even not even joining the team. We're going to be side to side with them, but I expect a lot more collaboration with those guys. So that's great.

We do have concerns about the open source commitment because like in Red dot it's very easy. Like we, as I said before in our employment contracts, we have this thing that you're allowed to contribute to anything. IBM has been very reassuring about us, like they clearly don't want to lose us and they want us to keep working the way we are. We are used to work, so probably nothing is going to change, but for us this is a bit surprising. Yeah.

I can't answer your question about where Red Hat is going because we won't even. Be there for such a big name, you know, Red Hat has been in the open source from the Linux and maybe maybe many other projects like Hibernate. I think that's really a big contribution and hopefully you guys can continue all this great work and, you know, support the community. So Sunny, as we reach the end of

our conversation, I have one last question before I let you go. I call this the tree technical leadership wisdom, but you can think of it simply just like advice that you want to give to the listeners. Maybe you can share some of your advice for us. Yeah, this is the tricky question. I thought about like the most important one. I realized this was actually advice given to me some years

ago. It took me a while to implement or realize how important it is. But I think it's very important to make yourself replaceable aggressively. So I think many of us see it working in this space the way you might suffer from, you know, imposter syndrome, right? Oh, I got here out of luck, but I don't really know as much as all these other smart people. I'm working, right. So you kind of tend to make yourself valuable so that you are kind of reassured that you're not going to be removed

next week. Right now, I have been working on Hibernate for a very long time. And then, you know, we created Quarkus and then I was involved in Quarkus and in Hibernate and I was the architect for Hibernate team, which means also like interfacing with all the other products that have to do something with Hibernate or integrate with it or and know about, you know, life cycle versions. How long are you working supporting this other branch? Lots of discussions and it was

just way too much. I love these projects, so I could not just quit any of them because I felt that some things were unfinished and were not clear or like some other people were not in a, the right position to replace me. And that was actually a problem. So I've been mentoring Joran Rodier now. It's extremely brilliant engineer in France and he's, he took over already. I have since last October, I believe the role of Hibernate architect. So I'm no longer official in

that's who I'm mentoring him. So I'm still kind of in the picture and I'm still working on Hibernate, right. But I really realize that it's important to make sure that I'm not indispensable. I had to go on paternal leave. And so I was literally, you know, not having sleep for four months. You, it's not good for the project if something like that happens. And you are not irreplaceable, right?

So it also prevented me from expanding and, like, diving deep into other important opportunities within these projects, right? Yeah, this is done now. I think we're all in a better position because also out of respect for the project, the other people, they were not getting the attention they needed or the direction they needed. Now that I have him and it's us. So yeah, making yourself indispensable a big mistake. But that's what's big time. And in the same space, I'm

thinking of interviews like. So I've been a trader for a very long time. And another funny thing is most of my colleagues, I've been the same for all those years. And I even had like the same manager for I think like 14 years and he didn't even quit. He retired at some point. Because, you know, all this long, I realized in the industry, this is really, really unusual. And for many, many years, I also did not interview anywhere else because, you know, you love the project.

You, we have a fantastic team. And so, you know, going and answer to a recruiter or somebody feels a bit like a betrayal of your best friends or your life, baby, right. I think that was a mistake as well. I, I did some more interviews in recent years and doing them, it helps or better understand my own value. And then therefore, you know, you get those very interesting offers. It builds up my confidence. And that helps, again, to fight imposter syndrome.

And that helps to realize that, you know, that the way you're working is valuable. It's valued by the others, and it just helps make you a better reader. I never learned because, you know, yeah, you'll get maybe the offer. It's assuring to know that if you left here, there are other opportunities, but then you still reflect like, well, I, I like this one should, but but it's still something that I even suggest my colleagues, you know,

do some interviews. Sometimes it's good and then, you know, we talked about it and the worst case, you, you're going to need a raise to stay. It's also not bad to truly listen to the others. Like one thing as a leader, especially in these groups know if that always resonates to me.

The six in the aerospace industry, they noted that most accidents have when you know, you have two pilots in an airplane, it's much more likely that an accident happens when the senior pilot is piloting because the other guy that's you know, they monitor each other. The junior one is less likely to speak up or if he does, he might not be respected in his opinion. That really struck with me and I think it applies also a lot in

other areas, right? Especially the technical things we work on. I've seen, you know, indeed all these chats and all these misunderstandings that we have. It happens quite often that somebody that's very junior or maybe has a very basic understanding of our frameworks, you know, when external user comes to us in the chat and asks something, he clearly has many misunderstandings or not read something, et cetera. And then, you know, his opinions get really discarded really quickly.

And sometimes, you know, many times it doesn't have value, right? But sometimes there are really important feedbacks in there. Also between colleagues, you know, there is a bit of a hierarchy. So if you are on top, it's very important to listen what the other guys say. And well, the opposite of listening truthfully is also like, I expect the others to also be truthful in what what they say.

And this is especially important now that we all work remotely and that we are far away and we don't know each other. The trust that there is between the people is so important. I had been blindsided once. Like there was one person that lies to me. And I realized later that I was like, I was very naive. I realized it had been many, many, many years that I've been working with lots of smart people and it had never happened to me, right?

So I completely am in working in a world in which the technical excellence is really reached by the fact that these people are very honest about what they see, what they are proceeding and all that. So I feel like it's when something doesn't, you know, you didn't do something that you had to do. I really value that people are very honest about what it is like. It's much better to hear that you didn't do it because yesterday you had other things on your mind and you didn't feel

like working. And that builds a much stronger relation. Then, you know, you you might need some slack or you might have a motivation issue. And then it's better if you tell me we can work on that together and that really helps creating a bonding in long term. But then we see in these teams that, you know, they we stayed together for a long time and we may create a good things

together. Yeah. Well, I really love that you know, listening and be open, say truthful thing, right, the psychological safety and you know, some people say. That's so that's. Pretty super important. So Sunny, thank you so much for coming here. Thank you. Again. This is our first time doing the in person podcast. I hope you enjoyed the experience. Yeah, good luck with all the open source projects out there. So again, thank you for your time. Thank you.