6 ms·

Because it's an open-source project, not commercial software. In your job, you have to special-case some things because the alternative is not delivering what

Because it's an open-source project, not commercial software. In your job, you have to special-case some things because the alternative is not delivering what the boss wants. Regardless of the problems this may cause, or how much tech debt it generates - those are (in the end) business decisions, and while you can make a case to the boss that implementing the special case feature is going to cause huge problems, it's the boss's call as to whether it gets implemented. In an open-source project the maintainer is the boss. If the maintainer thinks that the feature is going to cause problems, they're totally free to say "no, I'm not going to implement that feature". And, ofc, because it's FOSS, the user is totally free to fork it, or submit a PR for the feature, or whatever. > just got here from a Google search. I gotta say the replies from Remi sound defensively toxic. I'm not here to program the app, I'm just here to find a simple feature and/or request it. I think Remi sounds curt rather than toxic. There's no automatic right for anyone to go to a FOSS project and request a feature and have it implemented. The maintainer is perfectly within their rights to just say "no". It's their project, their code, their time, and they're free to do/not do anything they like with it.

somnic 2y ago
If you say "no, we're not pursuing this feature because it's impossible" and users have used other software that implements the feature to a reasonable degree of functionality, you're not doing yourself any favours in terms of shutting down demands. You'd be better off either not giving a reason at all, or giving reasons that are clearer to people who aren't as knowledgable.
- tuxone 2y ago
  Reasons are actually stated, they explained it is not feasible for the general case. Once the devs have made clear they don’t plan to do exceptions (as other softwares do) then users should accept it and move on instead of keep harassing volunteers.
  - account42 2y ago
    ... except VLC implements time-based seeking which has pretty much the same requirements and is consequently not possible with literally all files either. But both are possible with 99.99% of video files you will come accross. VLC developers are of course free to reject any feature request but if they do it by bullshitting their users (and that includes tacking on additional requirements that no user actually needs like perfect support for all formats under the sun) then they will be rightfully called out for it. Then throwing a tantrum and citing CoC violations is not going to improve things. It's their project so ultimately they get to choose to run it into the ground but this kind of behavior is not something I want to support as a user os I will stay away from VLC which includes not making helpful bug reports and not donating.
- FabHK 2y ago
  Why is it incumbent on the developers (who know their codebase and its capabilities better than the forum posters) to explain their decision to the forum posters begging for a feature, and not only explain it, but explain the decision and the reasoning behind in such clarity and depth that the forum posters (who might not even be programmers, let alone know the code base) understand it sufficiently well to refrain from begging and insulting?
  - wrasee 2y ago
    Because - and more so for the maintainers/managers of those projects - being able to communicate effectively is part of what it means to run a successful project? That may even mean that you have to hold yourself to a higher standard than some low-effort post on the part of some casual user. Especially if you're the boss, the maintainer, the leader. And if that's asymmetric then yes it is - but to be a maintainer/manager of a project is also asymmetric. Good managers might also promote that culture more widely across all the project's contributors and so yes it may apply to all developers, too. Not everyone that engages with your project is going to be perfect, some may even be rude. But as a representative of that project it's a skill to be able to cope with that, on behalf of the project (not you). I think one of the most underrated skills of a FOSS maintainer is a degree of fault-tolerance, to use a systems analogy. Or, you could argue that no, it's not incumbent on a maintainer to be anything, even to be kind. But then don't expect your users to come back.
wrasee 2y ago
But he didn't "just" say no: > If it's so easy, why are you not doing it? Talk is cheap. > I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers. I'd say that is pretty toxic. Specifically, that is no way to talk about other volunteer developers that contribute their time. It is precisely the kind of language that keeps people away from contributing to open source. It's the very definition of toxic.
- GuB-42 2y ago
  This is taken out of context. He actually respects contributors, including their decision to not implement reverse play. The meaning here is "if you think the existing contributors are as incompetent and lazy as you are implying, then do better". I think he got caught up in the argument and that he should have just put the question in a FAQ entry and lock the thread before people start mentioning nazis.
  - Bluestein 2y ago
    > lock the thread before people start mentioning nazis. Which will invariably happen. What was that "rule" called again?
    - gioo 2y ago
      It's Godwin's law (of Nazi analogies): https://en.wikipedia.org/wiki/Godwin%27s_law https://en.wikipedia.org/wiki/Godwin%27s_law
  - wrasee 2y ago
    Thanks for this. It seems you got that I misunderstood. I've clarified my point in another reply. Also agree that if this is a question that keeps coming up a much better response would be to simply explain your reasoning once in an FAQ that carefully presents the argument and point all future discussions to that entry. Done. To the average user, it's not at all obvious why reverse play is so much harder than it looks. Surely it's possible to understand that users might be confused by this? An well written FAQ on the subject would solve all of this.

somnic 2y ago

If you say "no, we're not pursuing this feature because it's impossible" and users have used other software that implements the feature to a reasonable degree of functionality, you're not doing yourself any favours in terms of shutting down demands. You'd be better off either not giving a reason at all, or giving reasons that are clearer to people who aren't as knowledgable.

tuxone 2y ago
Reasons are actually stated, they explained it is not feasible for the general case. Once the devs have made clear they don’t plan to do exceptions (as other softwares do) then users should accept it and move on instead of keep harassing volunteers.
- account42 2y ago
  ... except VLC implements time-based seeking which has pretty much the same requirements and is consequently not possible with literally all files either. But both are possible with 99.99% of video files you will come accross. VLC developers are of course free to reject any feature request but if they do it by bullshitting their users (and that includes tacking on additional requirements that no user actually needs like perfect support for all formats under the sun) then they will be rightfully called out for it. Then throwing a tantrum and citing CoC violations is not going to improve things. It's their project so ultimately they get to choose to run it into the ground but this kind of behavior is not something I want to support as a user os I will stay away from VLC which includes not making helpful bug reports and not donating.
FabHK 2y ago
Why is it incumbent on the developers (who know their codebase and its capabilities better than the forum posters) to explain their decision to the forum posters begging for a feature, and not only explain it, but explain the decision and the reasoning behind in such clarity and depth that the forum posters (who might not even be programmers, let alone know the code base) understand it sufficiently well to refrain from begging and insulting?
- wrasee 2y ago
  Because - and more so for the maintainers/managers of those projects - being able to communicate effectively is part of what it means to run a successful project? That may even mean that you have to hold yourself to a higher standard than some low-effort post on the part of some casual user. Especially if you're the boss, the maintainer, the leader. And if that's asymmetric then yes it is - but to be a maintainer/manager of a project is also asymmetric. Good managers might also promote that culture more widely across all the project's contributors and so yes it may apply to all developers, too. Not everyone that engages with your project is going to be perfect, some may even be rude. But as a representative of that project it's a skill to be able to cope with that, on behalf of the project (not you). I think one of the most underrated skills of a FOSS maintainer is a degree of fault-tolerance, to use a systems analogy. Or, you could argue that no, it's not incumbent on a maintainer to be anything, even to be kind. But then don't expect your users to come back.

wrasee 2y ago

But he didn't "just" say no: > If it's so easy, why are you not doing it? Talk is cheap. > I'll be waiting for your patch. Surely you're not as lazy and incompetent as the existing volunteer developers. I'd say that is pretty toxic. Specifically, that is no way to talk about other volunteer developers that contribute their time. It is precisely the kind of language that keeps people away from contributing to open source. It's the very definition of toxic.

GuB-42 2y ago
This is taken out of context. He actually respects contributors, including their decision to not implement reverse play. The meaning here is "if you think the existing contributors are as incompetent and lazy as you are implying, then do better". I think he got caught up in the argument and that he should have just put the question in a FAQ entry and lock the thread before people start mentioning nazis.
- Bluestein 2y ago
  > lock the thread before people start mentioning nazis. Which will invariably happen. What was that "rule" called again?
  - gioo 2y ago
    It's Godwin's law (of Nazi analogies): https://en.wikipedia.org/wiki/Godwin%27s_law https://en.wikipedia.org/wiki/Godwin%27s_law
- wrasee 2y ago
  Thanks for this. It seems you got that I misunderstood. I've clarified my point in another reply. Also agree that if this is a question that keeps coming up a much better response would be to simply explain your reasoning once in an FAQ that carefully presents the argument and point all future discussions to that entry. Done. To the average user, it's not at all obvious why reverse play is so much harder than it looks. Surely it's possible to understand that users might be confused by this? An well written FAQ on the subject would solve all of this.