I use it to inspect video frames by frames, particularly being able to go back one frame. VLC doesn't support it, this thread about the feature is hilarious https://forum.videolan.org/viewtopic.php?t=120627
replies(19):
But many players are able to do it for years.
with:
If it's so easy, why are you not doing it?
He's not just a butthole, he's a stereotypical open source developer butthole. On the other hand, if he worked for Microsoft, he'd be claiming that it takes a PhD to do it...
Nobody even offered to research how other players accomplish this. They just expect that because they believe it can be done someome should do the work for them.
At least Remi was actually andering questions on the forums.
This attitude towards open source maintainers is what's getting them all burned out.
Yes, you realistically cannot implement everything every user wants, but at the same time your software is meant to solve problems. Keeping direct communication with your users, and understanding what they find useful or not, should be the driving force of the design and features of your app.
FWIW, I've been on both sides of this discussion, as an OSS maintainer and user, and have experience with demanding users and arrogant and, yes, _lazy_ developers alike. Let's stop the narrative that users don't have the right to request features because they're not paying customers, and that this is driving developers to burn out. Communication is key to producing useful software regardless of its license. OSS development in particular is not just about throwing some code online and forgetting about it.
This says it all.
I agree that taking that kind of "closed" approach is not helpful.
you say that like it's a bad or even a surprising thing. for a lot of people that's the entire point of open source development - in their day jobs they do what they are required to do for the company that pays them, and then in their own open source projects they can do what genuinely interests them.
Did they? Because I read a bunch of the thread and “happy” is he last word I’d use to describe the developer’s sentiment. All I see is “let’s see you provide a patch, and I don’t believe you will”.
Everything about it screams that if a patch were provided, they’d do anything in their power to find reasons for refusal.
Even if I cared about VLC, reading those replies guarantees I would never attempt to submit the patch.
Have you tried to create a meaningful bug report (not feature request) that has not been previously reported and were rejected? If so your complaint is valid. I haven't so I don't know.
I hear you, but it could be something not so extreme. Lots of even more popular projects work fine with bug reporting system on GitHub, which everyone has access to.
> Have you tried to create a meaningful bug report (not feature request) that has not been previously reported and were rejected?
No I don't, I just want to subscribe to the issues I care, which you can't do without having an account..
It's a question of whose problems. It's highly unlikely that we perceive the same problems in the same order of priority, so why should I donate my time to your problems when I am already wishing for more time to implement the solutions to my own? In commercial software there's an obvious incentive to work on features that are in demand by people who will pay for them. Expecting people to act like that incentive still exists even when it doesn't is insane.
> I've been on both sides of this discussion, as an OSS maintainer and user, and have experience with demanding users and arrogant and, yes, _lazy_ developers alike.
The gall to call someone who doesn't want to work on your problems for free "lazy"... Now imagine that you voluntarily participate in a very active OSS project and there are tens of people like you who extend that massive middle finger over and over whenever they can't convince you to donate a work week to their esoteric dream feature.
> Let's stop the narrative that users don't have the right to request features because they're not paying customers, and that this is driving developers to burn out.
The "narrative", again, is "that you're not entitled to demand new features, as a (non-paying) user, you can't allocate dev's time to work on what you want." This is the card you insist is played too often, not that "users don't have the right to request features". I don't see how you could honestly get these two things mixed up.
> Keeping direct communication with your users, and understanding what they find useful or not, should be the driving force of the design and features of your app.
Who are you to decide what should motivate me?
The correct response would have been something like "it's more difficult to do and in some circumstances it will have very bad performance so we haven't done it yet".
This is classic "It's hard and I can't be bothered so I'll make up some technical reason why it's impossible". Programmers do this all the time and it's kind of annoying.
(And yes I understand video coding and I know why it's more difficult in some cases.)
If you just wish to solve your own problems, build things for yourself and keep it private. If, on the other hand, you want to help others and make your software public, then do right by the people who decided to try your software and listen to what they have to say.
How anyone can defend the attitude of the VLC developer in the thread linked above is beyond me.
It can, yes. There's nothing preventing it, except that it's a shitty way to work in the open, and you may as well make the project proprietary or source available. The maintainers might have their own vision of the project direction, and they may reject contributions, but refusing contributions outright is how forks are made. Nothing wrong with that either, but usually the projects that are more receptive and responsive to user feedback are the ones that users and developers gravitate towards.
Why is the artist obligated to do the work you think they should do? Why, if they don't do this work, should they be obligated to not release their work publicly?
FOSS is not an obligation to do everything that every user wants you to do. It's not an obligation to even communicate with those users. In fact, it comes explicitly with no warranty, even for fitness for any purpose.
The developer is a poor communicator, but how anybody can be defending those annoying, entitled, lazy users is beyond me.
> we don't implement a feature unless it works for the general cas
I used to make that mistake a lot. My boss would say "can we do this", for example report memory usage per operation. And I would say "no because sometimes memory is shared between operations so it would be meaningless". In other words I couldn't do it perfectly so I said we couldn't do it at all.
That's what the VLC guy is doing and I didn't realise until I worked with that boss that it is COMPLETELY WRONG!
Just because you can't do it perfectly doesn't mean giving up entirely is the best you can do. In cases like this you can absolutely do something that works sometimes but not in every case and that is way better for users than just giving up.
Lots of programmers fall into that trap though.
I guess if VLC has a feature, you can always expect it to work. That's their design choice. There's nothing "COMPLETELY WRONG" about that.
In the end, VLC has admitted defeat
Adding a requirement of supporting this perfectly with literally all formats you can think of is not reasonable at all since a video player that stuck to that principle would not be able to support any controls at all. It's the kind of bullshit excuse developers or corporations like to give when they don't want to implement something but also don't want to be honest about that.