JAN
8
2010

Goodbye Okular

The Okular team has never been all that big. Recently we lost Pino as the maintainer. His reasons are his reasons, but I can't say I blame him. I can personally no longer tolerate the level of abuse that we're seeing on bug reports. The latest example is Wishlist item 157284

I'm unsubscribed from the okular-devel mailing list. I'm not going to be in #okular. I'll still look at XPS bugs if I notice them.

It is difficult to leave. I really do care about Okular - I gave quite a lot of my time to improve it. It is a really nice application. However every time I looked at some bug comment insisting on a change (in something like the GUI that is subjective in the absence of actual usability study), I get disheartened. Even when I'm supposed to be working on something else, it gets to me. I've got better things to work on, where I'm not seeing that level of criticism of volunteer efforts.

I'd like to thank everyone involved in Okular, especially Albert and Pino for their maintainership, Piotr for the initial work, and Tobias for some inspirational work on the generator side.

Best wishes to Okular and its happy users.

Comments

I completely agree with you. It's sad that this matter ended with developers and some users frustrated but having read all comments on Bugzilla it seems to me that the original report and beginning or the discussion is respectful. Then, as you said, someone even provided a patch and lot of votes made clear that this particular feature was missed. Perhaps this could have been turned into an opportunity to get additional developers.

But after more than two years with the patch and demand for a solution no definitive answer was provided. I won't defend the lack of respect and violation of the code of conduct by some users and I understand the frustration suffered by the developers but I can't help but think the handling of this bug report wasn't appropriate. It really could end in users getting angry and/or forking. And no, I don't think appealing to good behaviour would change anything. People are people and you can't control how they'll react, so it would be better to be prepared to face situations like this in addition to trying to avoid them in the first place.


By Álvaro Manuel Recio Pérez at Sun, 01/10/2010 - 15:56

"how SHOULD it have been handled to get it implemented and not ignored for so long?"

I honestly don't think that in this case that was something the reporters had much control over. Without becoming pro-active, joining the project and taking the lead (e.g. getting a commit account and working on the source code with other Okular developers) which isn't exactly realistic, there wasn't much more to do. There were/are other issues at play with Okular, including ones that have me personally very frustrated with various groups of people (no, I won't go into details on that here; it's neither the time nor place).

"If the developers did not have time to implement the small patch what path did OUTSIDE developers have to do the work themselves and then have a code review?"

Nobody has to do anything, but if you want certain results there are faster and slower ways of accomplishing it. Getting directly involved is often the faster way.

"It looks to me like providing the patch WAS asking for a code review but maybe I missed something."

Yes, it was looking for a code review. What is probably being missed here is that Okular was not in the healthiest of places (note the mention of another developer leaving in Brad's blog entry; that hints at things).

So then what, right? Well, if you aren't directly involved you need to either become directly involved, be as patient as required and show respect in the process (which didn't happen in that bug report) or walk away and vote with your feet for some other piece of software if it is really that bad.

Additionally, we need to ensure that projects like Okular don't get to the point where they aren't capable of handling such a simple bug report.

This is not made easier by the demanding, loud and often quite obnoxious users who circle around KDE's blogs, bugs database and news articles. It is made easier by the helpful and positive (if even not always in agreement :) users who do.

So we all have improvements to be made, and in this case it was a situation of the people in the bug report simply not realizing that there may be more in the world of Okular than their particular need at that time.


By Aaron J. Seigo at Mon, 01/11/2010 - 19:21

If someone as a volunteer doesn't want to work on Okular, that is their perogative. I will thank them for their current contributions and not try to demand anything else from them. However, I really don't see that bug request as being abusive.

Someone kindly opened a bug request for a feature they wanted. Someone submitted a patch. Several people voted on it, and provided use cases (netbooks with 480 pixels) where the patch might be very useful.

Several users said they wouldn't be opposed to an alternate solution. They just wanted a means to go more full-screen when viewing content.

Considering KDE is also getting ported to phones, tablets, etc, and considering Aaron's comments on understanding the KDE SC is moving to a variety of devices, I think the request was very reasonable.

I don't see it as abusive in the least.

And for what it is worth, this is my #1 wish for a new Okular feature, .lit support.

http://bugs.kde.org/show_bug.cgi?id=158113


By enderandrew at Sun, 01/10/2010 - 17:14

I also wanted to say, that I love okular. Especially the navigation features! It's sad when a developer has to leave for such reasons.

I write myself a tiny plasma applet. Not much but its used by quite a few people. I've also got ranty requests (for binaries!) and a lot of duplicated feature requests in the forum (I have a bugtracker on bitbucket.org and linked it on kde-apps.org!). But I just ignore that. Features I don't like I don't implement. But if someone sends me a good patch that adds this feature as an option, I usually include it. Especially if its something tiny like making something hideable. Granted, this leads to a bit of a messy configuration dialog. Not very streamlined or adherent to HIG guidlines. The config dialog is actually to big for the eee pc (at least I got that told by users). I have to redesign it someday. Well, my applet is not part of KDE and so I don't have to worry about that.


By Mathias Panzenböck at Mon, 01/11/2010 - 22:53

Pages