Hacker News new | ask | show | jobs
by chithanh 1789 days ago
> 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.

1 comments

> 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).

> We're going to have to agree to disagree there.

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.