If anyone knows #Go and is looking for a project to help out with, Go-based #Signal protocol implementation library and a native #SailfishOS Signal client using it are in dire need of love:
Yes, I also prefer truly decentralized protocols, but Signal is where it's at currently with a lot of people, and it's way better than other popular options... So, we need independent clients.
@rysiek hasn't #Signal demanded people not connect third-party clients to their servers? In fact, any binaries not distributed by them (they refuse to let #FDroid distribute their app). These are only two of many reasons not to support Signal with your unpaid time:
I'd recommend working on a native #SailFish client for #Wire instead. They are a) already close to feature parity with Signal b) actively working towards server>server federation:
@strypey yeah, I am more interested in Briar (time to go full p2p decentralized).
I need Signal for work. It took 3 years to move 200+ journalists to Signal, I don't have 3 more years to now move them to Wire, unless Signal really fscks up big time.
For example, subscriptions to ticket trackers could be sold
You wanna open a ticket ?
You need to buy a 10$ annual subscription
Reading and triaging bugs is work and it should be payed
If that makes you outraged you are probably forgetting the "free" is intended as in freedom, not as in beer
@Wolf480pl feature requests are also useful if you're a developer who cares about #UX, as opposed to one who's scratching their own itch and sharing the results. What would be great is a tracker, where devs could give a time estimate for the feature, and an hourly rate, and users who want the feature could contribute until the required amount is raised. All within the same UI not on a separate site like #BountySource
@AbbieNormal @rysiek @sullybiker
I agree that estimates are weak, but I can think of two possibilities that might also work: one is the devs set a price, and the other that the users set a bounty. Each has pluses and minuses. The big plus is "all within the same environment, not a separate site".
> And it's not a given that users know what they want
Users are the *only* people who know what they want from software. That's why #agile practices that involve end users in the design of user-facing software produced better software, faster, and cheaper, than waterfall methods. They won't always share their needs with the developer, true, but that's all the more reason not to put a paywall between them and the place they can do so.
@bhaugen @Wolf480pl @rysiek @sullybiker