User Expectations and the Reality of Our Community
Notice: I debated if I should write this or not – so in advance, I apologize if it comes off as overly aggressive.
Lately I’ve been seeing a spike in users demands both on the user mailing list, the chat room, and on bug posts. More and more I’m seeing things like “this is a blocker for me and therefore it should have a higher priority.” This is truly a problematic trend and I hope that those reading this will take a moment to reflect on the impact that such comments have on our community.
It is incredibly easy to point fingers and tell someone else to “fix it.” Fortunately, that is not how our community has worked, nor is it how it works now. Angry comments that criticize a regression, or try to manipulate priorities/importance in order to get higher attention, is only bound to lead to developers and QA becoming unmotivated, avoiding the bug completely, etc . . .
So a couple incredibly important points:
- The Document Foundation (the non profit organization behind LibreOffice) has zero (yes, not one) paid developer. The implication of this is that there is literally not one single person on the project who can dictate how bugs are fixed.
- There are paid developers being paid by other companies – again TDF has zero power to influence these companies. They do incredible work and TDF has helped to develop an ecosystem where such third party, independent, companies can thrive.
- The remaining portion of our commits are wholly from volunteers. What does this mean – again, we have no power to dictate how a volunteer uses their time.
So what we try to do (at least in QA) is to do as much work as possible to help move the bug along, and then, it’s truly out of our hands. Things that can be done:
- Debug (for crashers especially): https://wiki.documentfoundation.org/Development/How_to_debug
- Bibisect (for regressions, 64 bit linux required): https://wiki.documentfoundation.org/QA/HowToBibisect
- Clear, simple reproducible steps + clean document for a test case.
- Prioritize correctly: This means WITHOUT bias of “this affects me” (honestly if developers are going to trust our priority/severity at all even as a guidance on what to fix, we must do this without bias, I completely avoid prioritizing my own bugs, even after 3 years on the project and thousands of bugs triaged). For guidance: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
- Most important at all: GIVE BACK. More and more I’m seeing users who give no time and demand the world – this is really just a way to demoralize the entire community. There are lots of teams – please do more than complain, because that really does nothing to improve the greatness which is Libreoffice.
Two particularly troublesome things have come up recently, more so in the past. Complaints about regressions have increased and this demand on developers to fix their regressions immediately, drop all other priorities, etc . . . etc . . . Some have gone so far as to ask if developers have “any responsibility to test their commits.” Rest assured – they test like crazy, but with >10,000,000 lines of codes, crazy shit happens. So getting involved earlier (download the pre-releases, daily builds and test) again….helps us help you. It’s easy to wait until a release, give zero time, and then start spamming wherever possible to complain. Second, enterprise users demanding we do things for free and prioritize highly because “this makes using LibreOffice in my office impossible.” For those of you using LibreOffice in an office, who are making money off of all of our volunteers incredible work, please consider getting support . . . making money off of others work and then complaining about the product you get is surely not the best approach to building a happy and healthy open source project.
So lastly – the options for bugs, they are pretty clear but I find myself having to repeat them over and over again:
- Submit a patch yourself (the code is free, go check it out);
- Find a family, friend, spouse, etc . . . to submit a patch (what are friends for right? 😉 );
- Pay for a fix (there are companies out there that are really quite fantastic);
- Wait patiently (yes that’s the last option – wait, complaining helps no one).
If you choose option #4 – I highly suggest doing the steps from the QA side to help move it along (help us help you!) – debugs and bibisects in particular.