Mozilla is ~83% funded by Google. That’s right- the maker of the dominant Chrome browser is mostly behind its own noteworthy “competitor”. When Google holds that much influence over Mozilla, I call it a false duopoly because consumers are duped into thinking the two are strongly competing with each other. In Mozilla’s effort to please Google and to a lesser extent the end users, it often gets caught pulling anti-user shenanigans. Users accept it because they see Firefox as the lesser of evils.
Even if it were a true duopoly, it would be insufficient anyway. For a tool that is so central to the UX of billions of people, there should be many more competitors.
public option
Every notable government has an online presence where they distribute information to the public. Yet they leave it to the public to come up with their own browser which may or may not be compatible with the public web service. In principle, if a government is going to distribute content to the public, they also have a duty to equip the public to be able to consume the content. Telling people to come up with their own private sector tools to reach the public sector is a bit off. It would be like telling citizens they can receive information about legislation that passes if they buy a private subscription to the Washington Post. The government should produce their own open source browser which adheres to open public standards and which all the gov websites are tested with.
I propose Italy
Italy is perhaps the only country in the world to have a “public money → public code” law, whereby any software development effort that is financed by the gov must be open source. So IMO Italy should develop a browser to be used to access websites of the Italian gov. Italy can save us from the false duopoly from Google.
That would be a blunt non-transparent/non-specific message to send. It’s not obvious /why/ the reg was denied.
Lemmy software is designed as comms software itself with email address disclosure optional. An admin can make it mandatory, but Lemmy’s design should cater for the email-free option regardless of how an admin toggles that setting.
I get that. People are accustomed to relying on email. But this is not an excuse for software deficiencies.
That can be accomplished without email. Email is a convenience at best. Some users have decided email is an inconvenience and do not use it. And Lemmy supports that -- partially.
Let’s be clear about who the software is expected to serve. The comms feature of giving feedback to users without an email account is not to directly serve the end user. Software should serve its user (the Lemmy admin in this case). A Lemmy admin does not want to take the time to express themselves on their decision only to have their msg blackholed. They don’t necessarily know that an email address is disposable. The end user benefits by extension, but it’s about creating software that serves the direct user of the s/w. If you’re an admin who makes email optional, you might still want to be able to get a msg to a user.
The core purpose of the Lemmy platform is communication. So relying on out-of-band tech is kind of embarrassing. Think of it from the dog food angle. An in-band msg has the advantage that the admin has more control (e.g. they can edit a msg later and they can know whether the msg has been fetched). Lemmy relying on email as a primary means of comms is a dog food problem.
The only sensible concession I would see to make is that there are a hell of a lot more important things for Lemmy devs to work on because the software has a lot of relatively serious defects. I’m talking about how great software would be coded, but extra diligent handling of denials should have a low triage in the big scheme of the state of where Lemmy is right now.