So, I am the one who disabled it from the Amazon Store. Not Amazon. So, the issue is not that dramatic.
The reason is that they refused to approve the 3.0 version of VLC, which meant that people were downloading a beta version from quite a long time ago, with lots of bugs. So I preferred to disable it instead of having more people load an old version.
The actual issue is that this precise version had a small database bug/issue that is very annoying to fix/work-around, and when you update, you lose the first audio playlist (video files, audio files, playlist files work fine). So, I'm not even sure that we can fix that in a correct way. But, for Amazon, they think it is a blocker. Sure, that meant that version is buggy, but that's even more the reason to not have more people download it.
Remember, we don't make any money from VLC, even if it is free, you are not the product (no ads, no spying, no telemetry).
Anyway, this is one of the reason why I dislike appstores: they make you lose a lot of time jumping through hoops, and the quality is not even there. All of those appstores have lots of crap in there. And, except the Google PlayStore (that has other issues), all the interfaces to upload/edit are very bad and buggy...
No disrespect intended, but I’d just like to point out-
“I don’t like app stores because they don’t have quality” and yet here they are trying to ensure quality, and you’re upset about it because they’re trying to stop users from having a bad experience by losing content they cared enough to curate? I’m not entirely sure the problem is in the review process here...
Exactly my point: they annoy us over a slight bug, and yet avoid upgrade to a stable version that fixes around 2000 bugs, over 2 years. So, for a small bug, they let thousands get unfixed.
And go on the appstores: how many scams, fake VLC and so on, do you see?
They claim to do reviews to get quality, and yet so many apps are fake, scams, and got approved nevertheless. It's the same on Apple, Windows, Android and Amazon.
A bug that results in data loss is not “slight” or “small”. I’d honestly rather have an unstable beta app than a production release that doesn’t offer a proper data migration. I’m disappointed that the VLC team would rather remove their app from an app store (again) than fix an issue with their app. At least Google is trying to look out for their users.
Troll me once shame on you, troll me twice shame on me.
What if the older, available version, which he just claimed had 2000 bugs, had 2000 bugs that resulted in data loss? How can you legitimately argue that he's not looking out for his users?
If that were the case and the developers knew it, then they should have pulled it from the store long before now.
Think about it - they didn’t pull the app because of the bugs. They pulled the app because they don’t agree with Amazon (of all people) that releasing a major version update with a bug known to cause personal data loss is totally unacceptable.
They’d rather not provide an app for the platform at all than work out a solution to a “slight bug” that would cause their users on that platform from losing their playlists during an update.
It seems to me that this is a case of a diva developer getting his feelings hurt, not a reasonable decision based on an unconsistent approval process. I can’t imagine a more used-hostile attitude than that.
Edit: somehow got it in my head that they pulled VLC from the Google Play Store.
To me it sounds like you've essentialized the target of your ire, while contextualizing what you prefer.
Even google shouldnt be above your reproach in a situation like this.
VLC is one of the shining beacons of the open source community, in my opinion. Just like every successful project that retains it's core values, compromise is key. The dude is all over this thread calmly explaining everything to anyone who asked. How does any of his behavior fit into any reasonable definition of diva?
Above reproach? For what? Enforcing their quality standards?
You are placing the “shining beacon of the open source community” above approach reproach, without a hint of awareness of the irony. Having a calm demeanor when explaining that they pulled the plug on VLC for FireTV because they couldn’t be bothered with fixing a “slight bug” that causes data loss (and which Amazon views as a “blocker”) doesn’t make the decision any less diva-like.
Unless a core value of VLC’s dev team is “egos over users”, I don’t see how you could possibly argue that this is a compromise. A compromise would have been leaving the old, buggy version of the app up with a note in the description that it is no longer supported.
I find it really disheartening that this is even a contentious opinion in the HN community. If the developer had come right out and said, “we just don’t have the resources to dedicate to fixing a major issue with the way playlists are exported from the current version of our app for FireTV, so we are discontinuing the app, effective immediately”, that would have been perfectly acceptable.
Instead, he diminished the severity of the bug and blamed the removal of the app on Amazon’s uneven approval process, despite the fact that the app does not meet one of the most basic criterion of Amazon’s approval process: “Apps do not put customer data at risk once installed”.
It’s the developer equivalent of knocking the Monopoly board off the table because you lost a turn. I don’t care how highly regarded the VLC development team is, this kind of behavior should be scorned rather than excused.
As your fellow developer, if perhaps at a different level of the stack, I've found that when my runtime performs in ways I didn't expect it too, the eventual solution almost always involves me questioning my own assumptions. The microcontroller didnt get statically discharged, my power rail is pulled to ground with an incorrect resistor. I didn't discover a compiler bug, I put a semicolon after my while statement, but before the curly brace.
I've also found that my ability to acknowledge this fact is linearly proportional to the time it takes to solve the bug.
My point is that the maintainers of VLC sit atop a mountain of software, used by tons of people with oodles of different use cases. The only methodology that ever allowed them to grow to their current stature has been to do whats right by the project. At some point, the large behemoths of Amazon, Google, et al, have to make compromises as well. If they hire enough support staff to have a personal relationship with every client, at the level of service you get from your local credit union, that becomes prohibitively expensive. In lieu of providing good service, they've settled for efficient service.
VLC is Kobe Beef. If Amazon wants to carry Kobe Beef, perhaps they should provide the level of service that Kobe Beef consumers demand. Lots of other folks love to advertise Kobe Beef, but balk at all of the transparency that an authentic Kobe Beef retailer has.
Amazon loves to throw its weight around, and claim its for the greater good. But to the extent they can't get what they want, they pull their top selling products from their shelves. They've even done this with books, the one of the markets they dominate to the highest degree.
But if we all demand that we be recognized as the one true expert in our fields, compromise becomes a four letter word.
They're forcing users to use an old buggy (and likely insecure) beta version of an app because a new stable version can't incorporate the old buggy beta version's playlists.
Because when people update from 2.1.1 to 3.0.0, they would lose their custom playlists. Indeed, it is a bit annoying, but we considered that it was not worth fixing that, notably for the FireTV UI, where it is very hard to create some playlists, therefore not many people are impacted.
> they would lose their custom playlists
> So, I'm not even sure that we can fix that in a correct way.
Got a link to an issue tracker for this? You're posting about a hard technical bug for an open source project to a community with "hacker" in the name. Maybe someone has a good idea.
I've gotten used to the android VLC functionality where it simply offers to play what is in storage. I'm not quite wrapping my head around what would be lost, why it matters, and why the playlist can't just be another object in storage.
I am constantly amazed that high-quality independent open-source projects like VLC are maintained so well, year after year.
Nope, that's the point: 3.0.0 will migrate playlists from the old stable version, but not from this beta version, because of a bug in this specific version.
And they don't want us to update it without this issue fixed.
This seems kind of moot, but is it possible to drop this type of playlist feature from VLC 3.0 and remove it from scope? If the feature has a blocking bug you could maybe just drop that feature entirely.
Well, now their VLC is gone altogether, AFAIK. I guess they can't use their incompatible playlists even if they were willing to keep 2.1.1, because 2.1.1 is gone from the store and all devices too.
Because your UI is bad and makes it difficult to create playlists, you don't want to bother fixing your bug that causes users' data to be lost, and you blame all of this on Amazon. I know you do all of this for free, but that doesn't mean you can blame all of your mistakes and problems on Amazon.
I see a whole bunch of assumptions and demands for a piece of free software that no one demanded you use.
In regards to who he can blame, and can't blame, can we all decide to blame you if he decides he's sick of ungrateful users and just stops development all together?
First of all I appreciate the work all of you put into VLC. This is my media player on desktop. I've tried lots of other players but always ended up going back.
In my respectful opinion as an outsider with no Amazon Fire device or association with Amazon, an update should not lose user bookmarks, playlists, documents, etc.
Users should feel confident clicking "update" on any software, ever.
I am sure you can empathize with your users if you consider what might happen if you updated Chrome or Firefox and lost all of your bookmarks. It is easy to see how users might feel the same way about playlists they put work into.
(Some users might even feel the same way about something much more trivial such as what page number they were on in each book in an ebook reader. If the ebook reader changes some internal structure it's easy to see how the new version might not migrate that stuff. I personally would find this okay, since I could find my old place within a few minutes.)
To try to empathize: how many hours might some of your users have spent making a custom playlist?
There is something big and important here: helping users feel confident always clicking "update" without a second thought.
Although the amount of work seems excessive in this case (and would be even more excessive in an ebook reader that has to export all of page numbers you're on, even if this is difficult technically) I think the secondary effect might be worth it.
I definitely see your point of view too, just thought I would offer this perspective.
Thanks again for all of your work, which I appreciate.
(You can ignore the other responses, your response to me is a challenge - you throw down the glove - but I found it fine and motivating and it made me resolve to check out the source code when I get home. I was only going to email you if I ended up being able to figure it out, and I expect maybe it really is too hard for me, if a format change or something else makes it really tricky, but your challenge had the effect I imagine it intended.)
That's because it would be a health issue. If I wrote a book for fun, and said you could have a free copy, it wouldn't be my responsibility to make sure you enjoy it. The VLC team does an amazing job at making their software solid anyway, so it's not even a good metaphor.
Oh come on. The parent is basically telling us what we should do and how we should do it. Maybe he's more skilled than us, maybe he has the time to fix, then a patch would be welcome.
VLC is a very small team, with around 10 developers, that maintain an open source B2C project, for free, on more platforms than so many (including huge teams or professional) projects, for > 10 years... Maybe, just maybe, we know how to evaluate the cost of a fix.
Amazon is being unrealistic by asking us to do a full migration of custom playlists, an option very seldomly used on Android TV (it's very hard to do in the UI of version they blocked us on, a contrario from the version we want to upgrade to), which we could not fix quickly without making sqlite crash.
But the point is: yes, there is a bug and we will get a bad vote from the people who rely on this. Sure. But that means that 99,9% of the millions of users will keep having the rest of the bugs, and there are a ton.
As with any open source volunteer project you are not a customer, you are a user, and no one has any obligation to do or correct anything for you or anyone else.
No one in such a project is beholden in any way whatsoever to meet the needs of any particular user or set of users. This particular point often causes spluttering disbelief and knee jerk reaction. Understand it carefully.
Yes, not meeting the needs of the largest set of users can cause the project to lose users or fail to grow. So what? Many open volunteer projects aren't out for glory and greatness, or millions of users. They're out just to build something _they_ need or are passionate about. All the better if others want to come along for the ride and benefit too.
There is nothing bad about telling users 'no we're not doing it' and by extension 'if you want that, build it yourself and we'll welcome it'.
It is quite staggering how many times 'users' will make demands or say 'do it this way' but feel offended when told 'do it yourself'. Users feel utterly entitled to make demands of project members and are utterly incredulous when such demands are turn back on them.
To be clear, I would not have objected to jdk saying "if you want that, build it yourself and we'll welcome it".
I completely accept that developers of open source volunteer projects have no obligation to fulfil any development request from any user, but the gp did not demand or even request any change. They gave their opinion about how software should work, and they asked a rhetorical question about data loss.
I just think that jdk could have made their point in a much more welcoming way, if they had been as polite and positive as the gp.
The cost to fix the bug is currently too great for them to devote resources to fixing it correctly, so s/he is merely trying to economize scarce resources here. This is an open source project we are talking about here, not a paid product.
If the gp thinks they have time on their hands, then by all means, the project will gladly accept patches.
jbk was not being honest or realistic, though. The gp was not volunteering, and jbk is not waiting for their patch.
It's fine to say "We don't have the resources to fix this", but jbk's sarcastic remark is not the best way to convey this. Of course, jbk is welcome to phrase their comments however they want, but I don't think that the way they chose was the most effective way to invite patches (and the gp presumably already knew that a valid patch would be accepted).
I think you and I mostly agree but I will try to address the possible source of your disagreement with his phrasing.
@jbk's original phrasing was:
I'm waiting for your patch. I'm very happy for your volunteering.
You probably think his first sentence is sarcasm but it is not for two reasons:
1. He followed it up with a gentler "I'm very happy for your volunteering."
2. I've been online long enough to know that his phrasing is a bit odd, a hint that the commenter is likely not a native speaker.
For a bit more context regarding #2, my suspicion is not unfounded. I remember the @jbk nickname from this highly upvoted post [0] last year, where he did something in the interest of the VLC project that a lot of people would find incredibly difficult to do under similar circumstances.
> 1. He followed it up with a gentler "I'm very happy for your volunteering."
"Gentler" seems like a euphemism to me. I read it instead as passive aggression which is generally considered rude and not a productive way of communicating with people.
Normal communication:
1. X makes an unreasonable demand of developer Y. "Users expect Z, you devs should always do Z."
2. Developer Y counters X's unreasonable demand with simple-to-follow reasoning: "I understand where you are coming from, but there are important technical reasons why we cannot do Z. Unless you have the time to dive into the code to understand those technical details (and perhaps even become a developer yourself in the process), you're just going to have to trust us on this point."
Benefits: clarity, positive example, trollproof.
Costs: several sentences, restraint.
Passive Aggressive Communication:
1. X makes an unreasonable demand of developer Y. "Users expect Z, you devs should always do Z."
2. Developer Y tries to "teach" X not to make unreasonable demands by making a similarly unreasonable demand. If devs should always do Z, and if current devs are too busy to do Z, then it should be so obvious that X must become a dev that Y will imply it in the response: "Thanks for volunteering!"
Benefit: brevity
Cost: confusion, consequent anger/humiliation in X that makes it harder for them to learn the ostensible lesson, troll food, negative example for future devs to follow, scary to potential devs, etc.
Why not include a small script that backs up their playlist before upgrading, whatever the workaround? Pretend it's one of those Apollo 13 duct tape situations, I'm sure some solution would come up! I don't use Amazon fire but love VLC.
If you are willing to consider ugly, shameful kludges, could you release a 2.1.2 version to Amazon that is just like 2.1.1 except that it creates and maintains an empty sacrificial audio playlist and puts that first on the list? People could update to that, and then update to 3.0.0.
It sounds like it would sacrifice the first playlist, which you describe is the problem, and leave all other playlists intact, which is what Amazon requires.
Does the publisher removing an app from the store (not just a specific version like 3.0) also uninstall the app from users' devices (like the 2.1.1 thing OP mentions)?
Seems like they're just prohibiting what can be considered a regression.
How is this any different from the majority of other software release policies? It's fairly common to block a release which fixes numerous things because it includes a fairly visible regression.
We tried that, they refused, because "removal of functionality". And if you update, you lose the playlists, but the new ones will work again, so the result would be similar.
The reason is that they refused to approve the 3.0 version of VLC, which meant that people were downloading a beta version from quite a long time ago, with lots of bugs. So I preferred to disable it instead of having more people load an old version.
The actual issue is that this precise version had a small database bug/issue that is very annoying to fix/work-around, and when you update, you lose the first audio playlist (video files, audio files, playlist files work fine). So, I'm not even sure that we can fix that in a correct way. But, for Amazon, they think it is a blocker. Sure, that meant that version is buggy, but that's even more the reason to not have more people download it.
Remember, we don't make any money from VLC, even if it is free, you are not the product (no ads, no spying, no telemetry).
Anyway, this is one of the reason why I dislike appstores: they make you lose a lot of time jumping through hoops, and the quality is not even there. All of those appstores have lots of crap in there. And, except the Google PlayStore (that has other issues), all the interfaces to upload/edit are very bad and buggy...