At the core of #AndroidDeveloperVerification are a couple potentially useful ideas. #Google has entirely wrapped them in a pile of anti-competitive garbage designed to defend their massive #monopoly profit margins, but nonetheless, those specific technical ideas might still be useful. #iOS's "notarization" is basically the same. That leads me to ask the key question:
What would a #FOSS-respecting system of #verification look like? What #identity info is useful for trusting the #developer?
@eighthave I'm guessing there are different levels and maybe conflicting aspects?
Anonymity on the dev side versus a need to trust on the users', and then the need to trust may be more or less strong depending on what the software does?
(not an expert, just not happy about what Google is doing right now, and so musing as a way to not be hopeless)
@jexner Can the human be anonymous while the "dev" is public? Clearly, we want the apps we use to be maintained by entities that we can trust. Are given names required for that? I think clearly not. For example, non-profits. People trust #EFF as an entity, even without knowing who everyone works there is, and whether the staff changes. So the entity can be trusted separately from human participants. I think developers are similar. Many trusted FOSS contributors operate under pseudonyms
@jexner your formulation seems like its going the right direction. On one hand, in the world of financial accountability, "know your customer" and showing government ID is normal. Borrowing an established practice makes sense when it works, but it doesn't feel right to apply that to developing software. I don't think the requirements are the same between finance and software, although sometimes similar. I haven't found a good breakdown though that maps that out.