Throughout the last few years’ time, I’ve been seeing sparks of an eternal discussion here and there. It’s a nuanced one, but if I could summarize, it’s about different feature development strategies we can follow to design things, especially if they’re aimed at a larger market. Specifically – when adding a feature, how complete and perfect should it be?
A while back, I read a Mastodon thread about VLC not implementing backwards per-frame skipping. At the surface level, it’s about an indignant user asking – what’s the deal with VLC not having a “go back a frame” button? A ton of video players have this feature implemented. There’s a forum thread linked, and, reading it could leave you with a good few conflicting emotions. Here’s a recap.
In what appears to be one of multiple threads asking about a ‘previous frame’ button in VLC, there’s an 82-post discussion involving multiple different VLC developers. The users’ argument is that it appears to be clearly technically possible to add a ‘previous frame’ button in practice, and the developers’ argument is that it’s technologically complex to implement in some cases – for certain formats, even impossible to implement! Let’s go into the developers’ stated reasoning in more details, then – here’s what you can find in the thread, to the best of my ability.
The Mess Of Video Formats And Human Emotions
Video compression can get complex – you wouldn’t be surprised to hear that, in overwhelming majority of video formats, the compression algorithms generally store between-frame changes, with occasional full frames stored so that seek isn’t too expensive. That said, it can get even more complex than this, with some formats being particularly seek-unfriendly due to blurring the line of what even constitutes a separate frame. Again, we have real-world examples of, but this does create a non-unified interface for users. I could not find an argument made by VLC devs addressing the suggestion to enable previous frame seek for some formats and not others, with UI changes to match, but I did find a different take.
The gist is, VLC developers don’t see a clean way to implement seek, as-is. Whatever other video players are doing, it needs to be investigated, and then it might turn out to be messy code where the principles won’t even transfer into VLC without creating a maintenance burden. The devs have the best insight into the codebase, as it stands, and if they. Of course, there’s been users who haven’t taken it lightly, and together with overwhelmingly reasonable messages, the thread has seen a considerable backlash to what appears to be an obvious feature that should’ve been added years ago.
Of course, it’s foolish to conclude that if some people are going over the line, their core argument is invalid. On the other hand, it doesn’t make for a pleasant atmosphere, and the reality of human condition will mean that the negative aspects of this discussion will make any work on such a feature an increasingly unpleasant experience for VLC developers. If they implement it now in some form, expect it to be a chorus of “told ya so”, which is hardly ever positive motivation.
But the entire atmosphere of the discussion is now clouded, to the point where the questions come to a common dead-end – how much can you really ask from an open-source developer? On one hand, asking for features is about the only way that a user can signal a need of theirs – but when that need has been clearly signaled as tricky to meet, users’ questions can quickly become annoying, and managing them becomes extra work of the sort that not all equipped with. Those of us who have manufactured products, have definitely felt the pain of replying to a trove of identical questions. Some developers prepare email template responses and tirelessly send those out, and some object to the very notion that this burden is their responsibility. When the implicit message from users is “you’re wrong about your area of expertise and denying it”, it can become pretty hard to engage in a calm manner, and that’s going to explain how quite a few of the VLC developer replies in the thread are pretty harsh.
VLC is a wonderful player that’s rightfully claimed a throne in the open-source software kingdom, and I personally rely on it in my day to day life. You can’t deny that VLC developers are doing something right, or rather, they’re doing a huge amount of things right – it’s hard to write a sophisticated large piece of software without a coherent view on how this software could work, and VLC has thrived in the open-source world for decades now. There’s a strong argument for trusting the developers’ judgment on this one.
And, there might be a strong argument for not trusting the developers, too.
Perfection Isn’t A Virtue
Now, the Mastodon thread I linked, approaches the issue from a different perspective. It pokes at the very core of the developers’ argument, and makes a strong stand in that something is fundamentally wrong with the way this issue is approached within VLC developer circle. It’s hard to deny that, in other players, the previous skip button just works when users expect it to work. Sure, it can’t work for some formats because compression is wacky, maybe it’s not expected that it will work for network streams, but from users’ perspective it’s a solved task in what seems to be every player except VLC. So, given all the points that we’ve just gone through, the Mastodon thread argues that the VLC developers are wrong about their area of expertise. That’s a strong claim – how is it made?
One of the developers’ core arguments is that the feature can’t work perfectly in all cases. The problem is that nobody was asking for perfection. If the developers’ responses are focused on how a feature can’t be implemented perfectly but the users in question aren’t asking for a perfect implementation, maybe the developers are approaching this feature from a fundamentally wrong angle.
This puts into question the claim of an implementation being complex – is it really as complex as you claim, or did you back yourself into a corner while striving for an impossible standard? Cases of developers backing themselves into a corner aren’t unheard of, and reading the thread, it’s really not clear that this is not the case. This results in developers strongly communicating a pretty common failure mode, while fervently denying it could be an option.
The communication disconnect isn’t helped by fundamentally conflicting messaging. Throughout the developers’ messages, if you are to treat them as seriously as possible, you can piece together these serious points: “we genuinely don’t know how to implement this to our standards, we don’t want to provide users with a bad user experience, but we are open to pull requests”. However, these points are surrounded by developers’ replies like “it’s not generally possible”, or “if it’s so easy, why aren’t you doing it”, or a variation of “this can’t be done perfectly [but it can be done for some cases]”.
Obviously, open-source developers aren’t gods expected to solve every feature request that ever appears, but that’s the thing, you’re supposed to be able to contribute to open-source, and it’s not really clear if anyone can contribute to solving this problem. There is two incompatible stances here – the first stance is “sorry, we don’t know, help us if you can”, and the second stance is “we expect perfection and know that to be impossible”. This incompatibility isn’t explicit, but it’s weaved throughout the thread when you read between the lines, and this makes it really tricky to determine if someone’s work would be appreciated in case someone were to go implement the feature and do a pull request.
Will your pull request get the positive bias as a solution to a problem that developers are struggling to solve for their users, as is a custom in open-source land, or will it get denigrated as a solution to a problem that can’t be solved perfectly anyway? I guess you just can’t know until you put in hours of work. When such an uncertainty is going to hover over you all throughout you figuring out a way to do a clean implementation, it’s going to be hard to forget that you could be doing literally anything more promising with your time instead. And, given negativity bias, will some people’s experience with VLC be tarnished by reading this forum thread as they’re looking for a solution to a problem that’s a keypress away in all other players?
Bridging The Gap
VLC users and VLC developers are talking past each other, while sending each other implicit messages with a fundamentally dismissive core. It’s an open-source community problem, but pull requests and forks are the wrong tools here. Besides, the technical problem is solved – one of the last posts in the forum thread tells us that there’s a plugin which solves this problem, adding a ‘previous frame’ button. It might require a finicky sequence of actions to operate or install, but it’s a solution better than switching to a different player, something that you’ll see quite a few people state in the thread in frustration.
When you put on the user gloves, what do you have to say to a developer trying to choose between an imperfectly implemented feature and not implementing it at all? Which one would you rather work with? And when you sit in a developer’s seat, how you do you feel about working away at an imperfect feature that might just turn into a maintenance burden, especially if you can’t get yourself comfortable with implementing it?
Ask Hackaday: What About Imperfect Features?
Source: Manila Flash Report
0 Comments