Tell HN: Contributing to Signal iOS is a waste of time
Despite instructions and links to the community forum on the GitHub repo [1] it is almost certainly a complete waste of your time to bother getting to know how to build, modify, and submit PRs to Signal for the iOS app.
Good quality PRs languish for years, half-ignored at best, despite comments from users and even ocassionally Signal employees that they are looked at.
The iOS app is in dire need of some improvements which many users have been contributing only to have their time completely wasted. I myself contributed a small change that would make it practical to delete all media from a chat.
I'm witholding donations until this situation improves.
[1] https://github.com/signalapp/Signal-iOS
10 comments
[ 3.3 ms ] story [ 34.8 ms ] threadGoogle makes AOSP open source not because they want to spend resources on your contributions, but for control. Pretty sure it's similar in many other projects like Flutter, Protobuf, gRPC, ... And not only Google, of course.
Signal is open source for security reasons: they want people to be able to audit the code. Definitely not to spend resources reviewing community contributions.
I know it sucks: I have spent time contributing perfectly valid features to open source projects that were never even reviewed. But on the other hand I have seen people try to contribute big PRs to projects I maintain and I am just not paid to adopt (and later maintain) their code.
Conclusion: unless you contribute something they directly need (a bugfix, or if you are lucky enough to contribute a feature they directly need better and faster than them), then don't bother. But that's valid for most open source projects.
> Signal is open source for security reasons
This seem to be in dispute. You can't distribute your own client. They provide the only binaries that can connect to the Signal network and so it's not possible to know if the source we see in the repo is the source used to build the client.
How are they misleading people? They are not saying "we will put resources and review all your contributions in the next day, and guarantee that all your feature requests will be implemented", are they?
That's a big misconception about open source, and people really need to start understanding how it works. Being open source means that they provide their code under some license. We usually like this license because it means that we can reuse the code, and it also means that we can audit it and debug it and potentially adapt it to our specific needs (like compile it for an unsupported device). This is already great.
Open source does NOT mean that they owe you anything at all. What you could have done before sending a contribution is ask them if they are interested and if they would have resources to help you. But I assume you didn't, did you?
I will be very honest: I do a lot of open source, and I maintain open source projects. For free, in my free time. Your behaviour is actually very common, and it drives me crazy (because I work for free and people complain about it). To the point where my new projects are actually proprietary. I don't need to open source my code if people complain about it. "Just go buy your proprietary stuff and leave me alone" is where that kind of behaviour has pushed me.
> This seem to be in dispute. You can't distribute your own client.
You can't distribute it, but you can certainly use it. I run a client I compiled myself. They just don't want to end up in a situation where everybody downloads a third-party Signal because it has fancy features and it eventually turns out that this third-party is a malware. Again that's a valid security concern.
By encouraging contributions but not accepting practically any of them and not communicating this. Go have a poke around yourself in the repo and the community forums and you'll see what I have already described happen many many times.
Edit the README and spell out the actual state of affairs and all that wasted effort will stop. It's not entitlement on behalf of contributors, it's Signal org falsely proposing to people and giving the impression to the wider world that they can contribute when in practical terms they cannot. I didn't even say it was deliberate and maybe it's not but it sure as heck is unprofessional.
> If your pull request follows all of the advice above but still has not been merged, this usually means that the developers haven't had time to review it yet. We understand that this might feel frustrating, and we apologize. The Signal team is still small, but we are hiring.
Again, this is how open source works. If you need the README to tell you "btw, we don't owe you anything, it is all best effort, and it may be that we don't have time to address your PR", then you haven't (yet) understood open source.
Don't take it personally, a ton of people complain like you do. Which is why I don't open source my code anymore. Then people can't benefit from it, but at least they won't feel like they can put pressure on me to work for them for free. Because that's exactly what you are doing: even if you did put efforts into your PR, you are asking them to work for you for free right now. And you don't only put pressure by complaining on their GitHub issues: you go one step further by trying to get the HN community to help you put pressure on them.
I have had a lot of people telling me "be careful: if you don't work in your free time to implement that feature for me, I won't use your project for free". And many people say that in a much less polite way.
[1]: https://github.com/signalapp/Signal-iOS/blob/main/CONTRIBUTI...
Are builds reproduceable? If not then it's a trust based security model if it can't be verified independently. I don't really have a strong opinion on this one way or another. But it's a point of contention one has to admit.
Is it perfect? No. Nothing is. But with arguments like this, you can complain about everything: "computers suck because there is no way to audit the millions of components that go into the hardware".
> If not then it's a trust based security model
I doubt "trust-based security model" is a thing. If you don't understand that there is always trust somewhere, then you have missed something about security.
If you can't trust the binary coming from the official stores, maybe you will trust the ones distributed by Signal. If you can't trust that, then you can build from sources. If you can't trust the sources, maybe you shouldn't use Signal.
But it goes further: can you trust your OS? Can you trust your hardware? There is always trust somewhere.