Hello, I'm Hossein Uricha, the developer community architect for the document foundation TDF. Today I'm going to talk about improving developer experience at LibreOffice.

This is the list of contents that I will provide today. First we will talk about the meaning of developer experience or DX. Then we will talk about the efforts in the 11 years of LibreOffice to improve developer experience.

It consists of culture, tools, and processes. And at last we will talk about the road ahead.

So, what is developer experience or DX? It is the overall experience of developers towards making a change or achieving a goal, which is usually fixing bugs or adding and implementing some feature.

It's about creating these changes as fast as possible and creating high quality changes. And it's not only about the tools and the code itself, but it's also about culture and processes.

The main tasks that we are thinking about are build, debug, test, run, and deploy.

And we will talk about these tasks in our talk. First, the culture. In LibreOffice we have a friendly culture because we accept and try to help newcomers get started as soon as possible.

In the developer community of LibreOffice we have a mix of volunteers and employees of companies. But when we look at the commits, we see that there is a balance between commits from individuals and companies.

The big features usually come from companies, but individuals also play a good role in fixing bugs and cleaning up the code, and the number of commits shows that.

We provide mentoring for the newcomers. We have interviews and calls with the newcomers in order to help them start development sooner and better.

And also, we have regular meetings for important decisions. A call named ESC call, or engineering steering committee call, which is held weekly. And once a year, we have a conference named LiboCon, and I hope that I can see you in the LiboCon 2022 in person.

This is the list of some of the tools that are used in LibreOffice development.

These tools help make life of LibreOffice developers easier. So, let's take a look at them. For continuous integration, we use Jenkins, and we support multiple IDEs.

And for the GUI design, we use Glade interface designer. We use CovertiScan for static code checking, Gerrit for code review, and OpenGroc as an online code search facility.

For bug tracking, we use Bugzilla, and we hope that the next version of Bugzilla will be released soon, so that we can benefit from all the changes from the previous version.

For the translations, we use WebLite as a web interface for translations, and all the translators use this web interface to translate the application into their own language. For cut coverage, we use LCOV, and for fuzzers that we have, we use LUBFuzzer,

and our fuzzers are based on that. Let's talk about the processes. First, the mentoring. As I've said, we have mentoring for the newcomers,

and we try to help them get started as soon as possible, and fix the problems they may encounter. We have EasyHacks, which is a simple task that helps a newcomer get started.

We have a lot of these EasyHacks. We have a bug bounty program by Integriti, which is about security bugs, and we also have tenders for more complicated tasks and some big features,

and companies or individuals can try to enroll in these tenders, and if they're chosen to do the tender, they will be paid for implementing a feature.

At last, we have Engineering Steering Committee, or ESC, which decides when some important issue is to be decided,

and as you know, the weekly Engineering Steering Committee call is the place that all these members gather together, and everyone can enroll in this ESC call.

Let's talk about tools and processes in more detail. First, the build tools. The old build system that was in use by OpenOffice was called tmake.

It was a custom build tool that was somehow like the standard make, but with a different syntax.

From the early days of LibreOffice, a new build system called gbuild replaced that, which is based on GenuMake. It works on Linux, Mac OS, VSTs, and Windows, using CYGV. And paired with LODE, which is LibreOffice development environment,

it can automate most of the build tasks. And in this way, most of the dependencies of LibreOffice is downloaded, compiled, and are used.

And this actually helps the developer to build such a complex code base of LibreOffice, with around 10 million lines of code, and several libraries, and over 200 modules.

These days, I can say that LibreOffice can build on every major platform, and using the latest compilers and tools.

For example, LibreOffice can now be built using Visual Studio 2022 under Windows. We use continuous integration to make sure that the submitted changes are okay on every platform.

So, as you can see here, the changes are built on Linux, Windows, Mac OS, and Android. And also, there are different configurations.

For example, on Linux, both CLang and GCC are used. In Android, as you can see, the build is done for both x86 Android and also ARM64 Android.

Other than building the code, we have several unit tests. We have C++ unit tests using CppUnit, and these are executed on every platform,

and if one of them fails, the code cannot be merged. And also, we have UI tests, which only run on Linux. For the GUI in OpenOffice, the GUI was created using code, which is error-prone and time-consuming.

But these days, every GUI in LibreOffice is created using Glade interface designer visually. And the fun fact here is that the Glade interface designer is for GTK,

but the power of VCL is that it provides the UI in every UI backend that VCL supports.

For example, QT or Windows, and you create a UI in Glade, and you can have a QT GUI out of it, which is very interesting.

We support several IDEs, for example, Visual Studio, VS Code, K2 Creator, Xcode, and many more. Just by invoking make with appropriate option, the project file for your desired IDE is created,

and you can easily open that project file in the IDE, and then you can use both the code completion and, more important compared to that, you can do debugging inside the IDE.

It is suggested that you configure and build LibreOffice before trying to use the code inside IDE and debug.

We provide mentoring, as I've said before, and we have dedicated mentors, including me and Elmery. We provide help via chats and jitsicles and screen sharing, if needed, with the newcomers to provide help and fix the problems that they may face.

And also, we try to review the manuals inside Vki and elsewhere in order to make sure that the instructions are correct and easy to use and understandable for the newcomers.

Then the easy hacks. As I've said before, easy hacks are simple tasks for the newcomers. We have several easy hacks with different difficulty levels from beginner to medium to interesting,

and they're categorized by different programming languages and skills, and all of these easy hacks are designed to help newcomers to grow in development and programming.

And as you can see in this picture, some of these easy hacks are described in the LibreOffice development blog, but all of these easy hacks can be found inside Bugzilla with a lot of information.

Let's talk about IRC and mailing lists. These are good places to get more information about LibreOffice development. If you want to get quick answers, you should refer to the IRC rooms inside LibreChat network.

LibreOffice dev is the development IRC room, and all of the rooms that you see here are breached to metrics, and you can use this URL to connect to the LibreOffice space

and use the benefits of metrics compared to the IRC and what IRC clients can provide. And if you want a more detailed answer, you can refer to the LibreOffice development mailing list.

We provide video tutorials. The one that you are seeing here is the Getting Started to LibreOffice Development video created by me for LibreOffice Conference 2021. But there are a lot more videos that are helpful for the developers,

and they can be found inside the development slash learning materials page inside the document foundation wiki. Wiki is the main source of information for the developers because it contains the latest and most recent information about the development,

for example, the latest build instructions. And as you can see here, many of the development related pages inside wiki

are translated into different languages. And this is something interesting for the developers that are using languages other than English.

We have a code review process, and each and every submission should go through this process. When you submit your code, your code is built by the help of Jenkins, and if it's okay, you will get a plus one.

And then your code is reviewed, and if the code is okay, it will get a plus two and then will be merged into the LibreOffice code. With code review, we try to improve the code quality and also help newcomers understand what qualities and what characteristics

their code should have in order to get merged into the LibreOffice code. Let's talk about the road ahead.

These are the new APIs and platforms that are actually in place today, but as they are relatively new and they will get improvements in the coming months and years,

I've added them inside the road ahead section. The first one is the LibreOffice kit, which is a new API for LibreOffice, which uses the tile rendering. It is used in LibreOffice online and elsewhere,

and it is much easier to use compared to the UNO API. And the other important thing about the LibreOffice kit is that it doesn't need any dependencies on LibreOffice libraries

because it is using tile rendering. The other thing that I should talk about here is WebAssembly, which allows to run LibreOffice in a browser,

and it is under development, but the code is merged into the master branch, so you can test it right now. Then the ScriptForge. It's a new API for LibreOffice automation, and I can say that it is very easy to use,

and it is very clean, and you can use that inside BASIC and Python, and I can suggest that to anyone that wants to start LibreOffice automation. Let's talk about the new build tools.

So the gbuild will continue to be in use, as there is no plan to change the main build tools, and the investment for converting the build to gbuild was a lot,

and it is working fine right now. But there are pretty minor works on adding other build tools, like Meson. Really minor works has shown that it is feasible to use it for the LibreOffice core, but a lot of efforts is needed to make that happen.

And for CMake, it is used successfully for the S-TECH examples, but currently there is no plan to use that for the LibreOffice core. And at last, the developer documentation

is something that can help LibreOffice developers a lot, and can improve the developer experience. So we have an old OpenOffice development book

that is quite old and is written by the people from Sun Microsystems, but other than that, we have a newer book,

which is dedicated and focused on UNO API. It is called Java LibreOffice Development. It is written by Dr. Andrew Davidson, and fortunately, it is recently released as a Creative Commons licensed book.

And it is a good platform for adding code snippets for other languages, like Python and BASIC, and probably C++. And it is focused on UNO API, I should say that.

So thank you. If you have any questions, I would be happy to answer them. Thank you very much.