Show more

@richiekhoo @sovtechfund yes, self-funded maintainers are an essential target for this kind of funding. I would also include volunteer maintainers, which is not the same thing. Many maintainers of key software pieces do want funding for the work, but funding can still go to others writing patches, etc

There also needs to be help getting companies understand that it is in their own interest to let their developers contribute to any project they rely on, no matter how indirectly they rely on it.

Major push to impose a U.S. site-blocking law. Nothing has changed since SOPA. Of course, lawful content would also be blocked arstechnica.com/tech-policy/20 #Quad9

@mvgorcum @paoloredaelli @element Ok, good to know! I was looking at the client, so I overlooked that. It is important that they've released key pieces, the bridges, as Let's hope this means they will contribute to the shared maintenance of the Matrix ecosystem for all the pieces they use.

Lots of hackers would love to go in an contribute to new projects. If there was a way that people could make a living doing that, we would greatly improve the ecosystem. Lots of devs want to improve the code they work on, but so many company ban employees from contributing to . One promising new model is maintenance funding from governments and foundations, like @sovtechfund and . Since 93% of codebases use , this affects the entire software ecosystem

4/4

Show thread

This also happens in companies, but the dynamic functions a bit differently. The maintainers will start quitting their jobs, reducing the number of people who know the code. In a number of companies, I've seen this happen where the end result is an essential system that no present employee understands. So no one is allowed to touch it as long as it is working. This happens at mega corps and small companies alike. I experienced it at Merrill Lynch, a wealthy bank that was always cutting costs 3/

Show thread

This can turn into a downward spiral, because it can drive away contributors, making things worse. Then only the ones who really feel responsible for their user base will continue working on it. Then ultimately they can burnout and the thing goes down in flames. The is a version of this dynamic. The maintainer was caught in that dynamic and felt he could not keep up, and was desparate for help since so many essential pieces of software rely on it.

2/

Show thread

There is a dynamic that arises when there is a growing difference between the amount of maintenance required and available developer time. The maintainers need help to keep up. Until then, they need to ensure that the essentials are maintained. That in turn makes it harder for others to contribute, because the maintainer cannot afford to take any risks that might trigger unexpected work sometime later. So the maintainers have less time to review, less time to help complete merge requests, etc 1/

@alloydflanagan @downey @neil From what I see, it is the other way around: Automattic has a pretty good track record of FOSS (Wordpress, Pocket Casts) while at this point, Beeper is mostly just a consumer of FOSS produced by others. So hopefully Automattic will follow the Pocket Casts pattern and start open sourcing the Beeper app.

@paoloredaelli yeah, I'm sure they're using the existing libraries from @element. The real question is: will they open up their app and get it on !

just acquired and , two chat apps that work with a bunch of bridges to popular apps :

* blog.beeper.com/2024/04/09/bee
* automattic.com/2024/04/09/auto

I really hope they open source it.
Since they are going for a fee-for-service model like Wordpress, I'm optimistic. This is key for breaking the network effects that companies rely on: .

@IzzyOnDroid @fdroidorg I'm happy to see @obfusk continuing with the very important work on signature analysis and the related tooling. I was worried she had stopped working on it after quitting F-Droid. That work is bigger than F-Droid, it is otherwise missing in the Android ecosystem.

@IzzyOnDroid @obfusk @fdroidorg sorry, I guess I should have started a new thread. I'm not so good at the social medias...

@IzzyOnDroid @obfusk @fdroidorg That was not directed at you, that was my takeaway from the analysis I posted in the 1/2 post. The TL;DR.

@IzzyOnDroid @obfusk @fdroidorg They key takeaway is:

If a binary repo maintainer is not careful about where they get their APKs and relies completely on AllowedAPKSigningKeys to verify the APKs, then this is an important issue.

2/2

@IzzyOnDroid @obfusk @fdroidorg All I'm asking is for . The tone you sense was my panic as I scrambled to figure out the proof-of-concept to ensure that users are kept safe. Signature verification is a key part of that. I cleared my schedule this morning to deal with this.

Thanks to @obfusk to doing the hard work of the proof-of-concept and the patch. I posted my preliminary analysis of the issue on gitlab.com/fdroid/fdroidserver

1/2

@IzzyOnDroid @obfusk @fdroidorg Part of the bug was known 11 months ago. The new proof-of-concept shows key details that were not previously known nor reported in the issue. Those were just dumped to the public. We asked for that yesterday, and you didn't send it to us, but withheld it to now publicly dump it. That code was posted to GitHub yesterday: github.com/obfusk/fdroid-fakes

You could have just sent us that link yesterday before tooting it, that would have been better.

@IzzyOnDroid @obfusk @fdroidorg you just published this wide open, yet before, you wouldn't even send us the POC code that you had? I think you two need to learn what means.

Show more
image/svg+xml Librem Chat image/svg+xml