 So let's go. Yes, welcome to this. So we actually tricked you. So we said maintaining a complex Java extension, but we actually meant maintaining volmux. So how that was done, what were the challenges, what's the history there, what's the feature set, like what is it in the first place, so you get the whole shebang, and some outlook, like we got some plans there, what to do with it. Yeah, welcome. Also Björn, as I said, one of the volmux authors happens to be here in Italy, accidentally, and I'm very glad to have you explaining all the gory details. Hi, and thank you Thorsten for the invitation, the integration. I feel a bit new, and the whole people of history. So yeah, and I'm going to start with the agenda, and we are going to start with the history and the architecture of the volmux. And so I jump to the next page. And so a few words into the history of volmux, and it's a bit time ago, and it was 2004, and Munich, they had Windows NT, Windows 2000, and yeah, they decided to upgrade and to use the volmux. And yes, this was in 2004, and and yeah, so yeah, every departure needs some management for forms, and yeah, I come to this point later, and so they started to develop the volmux, and we have some key major changes, and for example, in 2013, what's the migration from OpenOffice 3.1 to the right, OpenOffice 3.1? Does that work? Oh yes, it does. Okay. Yeah, I think it was 3.1-ish or something, so it was not the very latest OpenOffice version, so history of course is that the Linux project started with OpenOffice, and then it was a relatively long period of migration, and I think the first production volmux was 2008 or something, and it was also the first time that the source was published, so we're kind of skipping your hat here, and skipping most of the OpenOffice details. Okay, so and the next, and you could say what's coming after 2030, for example in 2014, 2016, and there were a lot of new futures, and that every department, that some department needs, so this is more about fixing futures, and the next? And actually, if you look at the amount of changes, the migration from OpenOffice to LibreOffice 3.6, in that case, was quite massive, so there was some, so that there wasn't single, there were two releases that were really quite large, and that was one of them, for obvious reasons, we did change quite a bit and LibreOffice back in the day, so that it was reflected in volmux. So we are in, yeah, then 2017 Munich and announces to return to Microsoft, but the volmux is a platform independent, and we continue to and support and partly integrated new features, but yeah, and to this time, we also first communicate with a lot of VR and zip, and to hand over the volmux at some time, and so, yeah, and moving from and to Maven, and build the whole build system, and yeah, and it was added, and yeah, the next big change was the, we want to go away from Java Swing, and to the native LibreOffice controls, and we are coming to this point later, and we added the integration of the form UI, so when you have a form, you have to fill out the form in some way, and this was an extra separate window, and because of the Java UI, Java Swing UI, and we integrated it in the LibreOffice sidebar, yes, that's, that is the one. Right, and also the last one is one of the largest, that's actually from a single release, the step from 17 to 18 was the largest with 96K lines touched repeatedly sometimes, so it was quite a large cleanup there, and largely bad. What's interesting is that the time frames, when you look like when it was announced and decided to migrate, and what's, let's say, how long the project still continues, and also how much, sorry, that might be better, and how much work is still invested down. Right, so yeah, the, I think that is, you wanted to cover that? I forgot, so let's move, skip over that quickly, so basically it's Java, and it's an extension, so that's those two design decisions that were kind of, they're kind of unmodifiable, can't really get out of that without dumping everything, and that's kind of decision, like mid 9, mid 2000, due to the fact that they wanted something integrated with OpenOffice back in the day, and Java was kind of a nice language cross-platform, so you could, it was already then that when they migrated from Windows to Linux that they needed cross-platform functionality, and quite some cool stuff there, and Python wasn't quite there yet, in terms of ubiquitous availability, and also like quality of implementation, so Java was a very obvious choice. Very quickly the reason for that, that it was also a very nice and good thing that that happened already, because that's kind of, yeah, let's say, technical debt with quite some fallout, like very brittle, due to the fact that Java Spring has a separate GUI threat, or a separate event handling, and it all has to happen in a GUI threat, so you had lots of threats switching there in the implementation, and subsequently deadlocks, and lots of work arounds for that, so yeah, just long story short, that's some good riddance to that, and it's good that it's gone, and it's also less code, which is always good. So why this thing in the first place? That's also kind of a bit shrouded in secrecy, but the decision was to have, there was nothing before, so there was this joint set of proprietary solutions, and of course that had to go, with this decision to migrate to Linux that had to be replaced with something, and there was nothing available for Linux, and what was there before for Windows was also not very nice, because it was kind of disjoint, so they kind of set off and decided to do something nicely integrated, and yeah, there should be all this kind of what you can do with documents and templates that should be all in one sealed, like the letter hats, how to handle that, like what's the name, what's your extension, when something changes, like I don't know, CT gets a new logo, a new design, the form templates, and the mail merge, because it's logically very very close to each other, and it should integrate very deeply with the Office Suite, and it had to be open source, which is great, and it's licensed since 2008 under the European Union Public License, UPL, which is a copy left, we copy left license, also very nice and compatible to what LibreOffice does, and with that, back to Björn. Thank you, and so, and we thought it would be nice that we can show something in practical, small demo, so I show an example for the mail merge, it's a very simple text. So just to draw your attention to the fact that the sidebar is doing something very custom here? Yes, yes, the sidebar, you have a config for every client, it's hosted on, Linux hosted server, where it's received the config, and this is just a basic config with a letterhead and some other examples, and this icon is for the mail merge, and so you can support an ODS file or a database, it could be MySQL, it could be Oracle, and it doesn't really matter, and so I have, now it's not a database, it's simply a file with 1000 datasets, it's random names and some other things, and what you can do now is you can simply, as it reads the header of the ODS file, first name and so on, and you can simply choose it in the mail merge UI here, so you can just set it in the document, what's on the cursor position, and you have some special fields, which are functions in the Walmux, for example, you can do an if condition, I have set here and the data source is a number of children, some values, and here I have an if condition that you can set, and that's widely used in all departure and department, and so when you, it reads the data source, and when a number of children is null, and then you get 50 euro, and when you have one child, and then it's 100 euro, and so on, it's just a simple example, but that's one thing that's heavily mostly used, and so you have a preview function, and I quickly set, and you can see here, and it depends what the value is in the data source, and what we have set in the if condition, and it will be set in the document, and so we are mostly finished, and I select here, you can select how many data sets you, and it should then print, or generate, you can select them in ODT or PDF, and I will take just one of them, and you notice that it's, I mean, it's mail merge, so it's essentially the same, like LibreOffice has built in, just with lots and lots and lots of extra belts and whistles kind of geared towards like complex needs, so it's kind of the pro version of that, and it kind of makes sense to have that as an extension rather than have the complexity there for everyone, so yeah, and same is true for other features of that, and okay, so I have to do a quick look at what's the next page is for, and I have another, and it's a form, so it's a quick demonstration of how forms are filled out, and some functionality behind that, and for example, you have what's also widely used in our visibility, so you have some condition that comes from a field here, and or from the database, and you will, it turns on visibility on or off, and depending on the value, for example, you have a combo box here, and we'll choose this one, and you can see here you have now another text fragment, and that will be shown depending on what I'm selecting here, and what I select here, and that's a feature which is widely used. And one more comment, so the meta data that controls all of that behavior that's included in the templates and the ODF files, and it's implemented as some RDF, so it kind of survives load and save, it's always like connected to the document, kind of nice demo of the power of the extensibility really of both LibreOffice and ODF now. And for example, this is the RDF file, and you can see what is generated, and of course you don't write such things, and by all by hand, and you have, and it's a part of the wallbox, and it's part of the wallbox, it's the formbox, and this is the tool where you create and create a form and can adapt functions, you can set functions. And even comes with documentation? Even with a home page, olmux.org, and I should show how you can mix and documents to one final document, so you can insert fragments in the main document, and so when you have, for example, there's a new legal new paragraph for FAMC, and you don't need to change the whole document, you can change the fragment of fragment, and that will be loaded in the main document, and so it's easier to maintain. It's a bit like if you are a programmer, it's a bit like includes, so you just have one copy of this of this footer, and if you're bored, changes, you don't need to change 100 templates, you just change the one include and then get it for free, or the logo of your company or of your city. Yes, it has an integration for LDAP, and so in the letterhead, and if some employee at the Munich department needs to send a letter to someone, and it will be automatically filled by the values which are in the LDAP database, and so it will be filled out in the letterhead, and to the last point creates a result template for workflow, so you can control it if some value in the database is true, and you can insert, but it will be inserted in another fragment to the main document. So, given that we're running slowly out of time, so all of that, so first of all, personally, as you might have heard, I'm a great fan because that's kind of super powerful, you find that there's professional packages that offer you that, but they are kind of really expensive, and they're used by banks and other institutions that produce a lot of documents, like a government, but none of that is open source. There are a few open source solutions, but none of that that I would know is as nicely integrated with LibreOffice as something that is usually in front of the user's eye. So, the idea was that with us slowly coming to an end as a project, that it would be a good idea at least to ask the Document Foundation if they would take over the project, there are still users out there, so mostly smaller municipalities that we know of, but as always with open source you usually don't know who's using your software unless something breaks, or unless maintenance stops, and then people will kind of show up and say, uh-huh, but can you fix the bug or we need this? So, yeah, that was the idea, that it would be kind of a nice, nice match there. Actually, TDF is already hosting the website, and I believe Ricky since 2012 or something, so that's already kind of strong ties. The pitch would be like an extremely nice showcase for what is possible with ODF, and as an extension kind of, I mean, you have extensions that use one feature, but that's an extension that kind of uses all the features including the sidebar. It's been in continuous development, has been quite some cleanup recently, so that's kind of reasonably future proofish code. Nice success story beyond the fact that, certainly Munich is migrating away, but I mean it's in production since 2008, so that it should come for something, you know, that's the third largest city in Germany, and yeah, okay, that's probably a loss. Yeah, and it's kind of like, so it's kind of one-stop-shop in terms of this, like what you need for everything that produces documents, so you can do it all there in one place. And there is some commitment from the city of Munich, and also from my company, because yeah, I think it's a great piece of software, and I do believe that there's, that it has a future, and that there might even be business there, that once it's at TDF, and perhaps a bit cleaned up, and just a bit less German, and yeah, that there's other people being getting interested in that, or that those people that are still using it, say yeah, well, we might need some support or maintenance there. So there's some commitment for cleanup and improvement, and also a limited commitment to maintain that for at least a year or two, so that it's not like cold to dump and run away. And with that, we're one minute over, so if you've got any questions, maybe that's something for the hallway. Thank you very much. Thank you.