Ever heard the term “scratching your own itch”? Wiktionary describes it as “doing something out of motivation to solve a personal problem”. In the world of free and open source software development, this happens a lot! Anyone can contribute to FOSS projects like LibreOffice, and help to improve them.
And that’s exactly what Rafael Lima did, with a long-standing limitation in LibreOffice. He rolled up his sleeves, got to work, and fixed it. Here’s what he had to say:
There’s a nice story behind my fixing this bug, so I’ll share it with you…
First of all, this is the bug that made me want to become a LibreOffice contributor.
For some background, I work at an Engineering School in Brazil and one of the subjects that I teach is Operations Research, so I often need to use linear programming solvers to, well, solve optimization problems. And since I’m a Linux user and an Open Source advocate, I would love to be able to use LibreOffice in my lectures.
But the first time I attempted to use the solver (maybe some 5 or 6 years ago), I was surprised to learn that the solver settings were not saved to the file. This was a complete showstopper, because students would have to prepare models in a spreadsheet and then hand them over to me for evaluation, but since it was not possible to save solver settings, I was never able to use LibreOffice’s solver in my lectures. This was really a shame, since the linear solvers available in LibreOffice are superior to what we find in the competition.
Some time later I opened a bug report to complain about the missing feature, which turned out to be a duplicate of bug 38948. At the time I was not a contributor and did not understand how things actually worked in open source, so my bug report had a quite angry note to it (which today I regret). But I could not understand why LibreOffice had overlooked such an important feature for so long.
After that, I kept on following LibreOffice on social networks, specially on Reddit, and noticed that many users had other “missing features” that they would like to have implemented, and then people on the threads often explained that LibreOffice is a community project and that someone would have to step up and implement the feature.
So in 2020, I decided to join The Document Foundation and become a contributor… but implementing this solver feature would not be an easy task. So I started with contributions that are more accessible for beginners, such as documentation, help pages, and so on. Then I started fixing some smaller bugs (easy hacks) to get to know LibreOffice’s huge codebase. And finally in early 2023 I felt comfortable implementing this solver feature.
What makes me glad is that next semester when LibreOffice 7.6 is out, I’ll be able to use it in my Operations Research classes and students will have a nice reason to consider LibreOffice for optimization tasks.
I still have some more improvements that I would like to make to the solver, such as changing the user interface, and enhancing the solver API so that it becomes easier to build and solve models using Basic and Python macros.
Also, I’m planning to attend the LibreOffice Conference this year to discuss some technical aspects about the fix for this bug, as well as some solver API proposals that I would like to put forward.
Thanks, Rafael – great work. We’re looking forward to seeing you at the conference this year too! And everyone else is welcome to join our QA community and do great things, like Rafael did here.