What a buzz kill. If I understand you correctly we shouldn't have expectations or constructive criticism on stuff we don't directly pay money for. I think that's nonsense. Does this only apply to certain opinions?
You are not paying money for Signal. But by using it, and getting others to use it, you are definitely improving their position on the market by helping them become a monopoly. Money isn't everything.
> What a buzz kill. If I understand you correctly we shouldn't have expectations or constructive criticism on stuff we don't directly pay money for. I think that's nonsense. Does this only apply to certain opinions?
You can have constructive criticisms, but they have to actually be reasonable and constructive. It's not reasonable or constructive to expect their software to never have bugs (i.e. be outraged when they have one); to rag on them because they didn't fix some bug more quickly than they may have been able to; to throw around labels like "proprietary" just because they don't release something on your schedule; to be bitter that their vision is not your vision (e.g. they won't implement some client or server feature you want), etc. All of that is in this thread.
Signal, for whatever reason, seems to attract a lot of entitled complaints like the ones I enumerated. I don't know exactly why, but it probably involves some combination of contrarianism, being in popular software category, and people who want to feel better for having picked a different team.
Signal isn't perfect software for me: I really wish they had an unencrypted message export feature, for instance. But I understand that doesn't fit into their vision, and instead of bitching about it, I just have it on my todo list to write my own (and have done some preliminary work on it).
> You are not paying money for Signal. But by using it, and getting others to use it, you are definitely improving their position on the market by helping them become a monopoly. Money isn't everything.
What now? Signal is nowhere near being monopoly, and even if they were, they're a non-profit, which makes the idea far less threatening.
> It's not reasonable or constructive to expect their software to never have bugs
I think nobody demanded anything of that sort, that is just a strawman. What was actually demanded is that priority of such bugs be raised, and perhaps users be adequately warned about known defects that may compromise the confidentiality of their messages.
That Signal developers didn't have an idea what was going on for 6 months? And then it turned out to be similar to that other stale/invalid database bug where messages were sent to unintended recipients? Back then fixing only the bug at hand but not taking steps to ensure that the type of bug (wrongly matching expired message IDs to existing messages) won't happen again? Doesn't paint them in the best light.
> to throw around labels like "proprietary" just because they don't release something on your schedule
I throw around the label "proprietary" because software which doesn't come with source code is in fact, proprietary. If Signal pushes new server code to production and keep its source to themselves, calling that still "open source" requires serious mental gymnastics.
> Signal, for whatever reason, seems to attract a lot of entitled complaints like the ones I enumerated.
No, besides your strawman the other commenters were all reasonable and constructive.
> I throw around the label "proprietary" because software which doesn't come with source code is in fact, proprietary. If Signal pushes new server code to production and keep its source to themselves, calling that still "open source" requires serious mental gymnastics.
It comes with source code, just not on your time-frame. That's still open source.
And if that's unacceptable to you, just use something else.
>> Signal, for whatever reason, seems to attract a lot of entitled complaints like the ones I enumerated.
> No, besides your strawman the other commenters were all reasonable and constructive.
We're going to have to agree to disagree there.
But if you want to (for instance) implement a plan so we can be "assured that this type of issue won't occur again" in Signal (https://news.ycombinator.com/item?id=27951759), be my guest. Or maybe you could develop a fork of it and show us your vision for it (including a source release schedule that's satisfying to you, a federated protocol, and all the the other demands in ITT).
Everyone can of course have their own opinions. But they cannot have their own facts, a discussion does not work that way.
Whether one considers some statement as entitled, that is an opinion and we can disagree about this.
But whether a program is open source or not is a fact. It doesn't matter if the source code is going to be released a day or a year after the Signal server has been pushed into production, at that very moment the program is not open source. Your comment about my time-frame is irrelevant. In the github issue 11101 link I posted above is Moxie admitting to running versions of the server that are ahead of the public git repository. These are factually closed source, and you continuing to argue against that fact doesn't reflect well on you, nor the ability to have serious discussions with you.
To be pedantic, only the ones that posses the binary need the source code for something to be open source. Since they did not publish the binary and since they have the source code we could say that it is actually open source software.
