MicroG Project: A re-implementation of Google's Android apps and libraries
I don't know about this. Android is not on its way to becoming a proprietary operating system, it's as open as it's ever been. Rather the author seems to be trying to redefine "operating system" to include things that have never been a part of such a term before, like online message routing and mapping services. Since when do we define "operating system" as including libraries for specific online services? User interface libraries, kernels, drivers, multimedia frameworks, sure ... but mapping services?<p>The underlying theme connecting these libraries is that they're clients for Google's proprietary protocols. Sometimes there are good reasons for these protocols to be proprietary. In the case of Maps (which I worked on some years ago) it's because Google's licenses for some data sets are specific to Google, they aren't allowed to just throw it all out there via an open protocol, and they are expected to discover and block non-Google client apps. In the case of the Market, they want to defend against things like abusive install count inflation. They also like to redesign products and change features whenever they want. All these things are easier when you can change the protocol at will because there's only one client to support, and the client team sit next to the server team.<p>Note for example that the microG folks have had to implement "DroidGuard", a system that tries to spot scripting of Google's servers from non-approved clients. The microG implementation contains fake data that is sent back to the servers. This risks legitimate users being mis-identified as abusers and potentially having their accounts suspended. That risk must be understood by the microG authors but they don't inform you of it anywhere, which seems poor.<p>Given that both the protocols and client libraries can change at any time without announcement, I don't see how microG users will ever have stable devices. Nor do I see why they care. Even if they reimplement the client libraries Signal and other apps will still be dependent upon the proprietary servers.<p>If they want a version of Signal that's entirely Google independent the right thing to do is set up and run a competitor to the actual messaging service, not just reimplement a thin protocol wrapper and call it a day.