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?
@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.
@eighthave Fully agree!
I guess it is somewhat difficult for an independent dev to do the scaffolding needed, but as long as you build "small" software, it may not have to be as complex as creating an organisation.
Is the question then simply: how do we know which "entities" are trusted and how do we make sure, a particular piece of code is "from that entity"?