Al, Mark is right that if you start calling Android a "closed" environment, and especially if you throw out the word "lawsuit", you can expect Google employees, among other people, to get upset. Just being on the Android mailing lists and seeing all the different conversations has shown me exactly how many problems Google has had to deal with and how many risks they're taking by making the platform as open as it already is. Many of people's concerns are clearly going to be address in future SDK versions, and many of them are just not.
You have every right to pressure Google and remind them of their continual responsibilities to keep Android open, the marketplaces equal, etc. I will too. But you should take care to do it in a friendly way -- and so far, you have not. -- Eric On Oct 22, 1:59 pm, Al Sutton <[EMAIL PROTECTED]> wrote: > Mark Murphy wrote: > > I'm not disagreeing that this is an issue. All I ask is that you pick a > > different adjective pair than open/closed, which are charged terms in > > open source, just like the "lawsuits" that you tossed around in an > > earlier post on this thread. Language means a lot, particularly on open > > source projects. > > > Of course, my mental thesaurus is failing me on what another suitable > > pair of adjectives would be, which certainly weakens my position... ;-) > > Answers in an email please. I'm open to suggestions, but Google used > "Open" in a lot of contexts in the launch press release > (http://www.google.com/intl/en/press/pressrel/20071105_mobile_open.html) > > > > > Anything, including this limitation, is fixable given an appropriate > > patch. Hence, the process for fixing this limitation is straightforward: > > > 1. Write a patch. > > > 2. Propose the patch. > > > 3. If/when it gets shot down, organize the vox populi of the Android > > developer community to try to change the opinion (e.g., lobby for more > > non-Googlers in the governance system, petition for the patch to be > > accepted) > > > 4. If/when #3 does not resolve the issue, fork the project and convince > > carriers and handset manufacturers to use your fork rather than Android > > itself > > > That process is certainly not easy. However, it is the process that is > > used, day in and day out, on all sorts of open source projects. It is > > the process that, by their actions to date, Android appears to follow > > itself and is expecting for us to follow. And, while difficult, it is > > the simplest approach, short of armed conflict, to get what you want. > > > You don't have to follow the process. You can merely vent if you want -- > > that's what [android-discuss] is for (and I do really appreciate your > > moving this thread here). > > > I'm just hoping we can be careful on the lingo. > > hackbods statement was > > "Yes, these APIs are not in the SDK, but even if they > were, you couldn't use them because they are protected by a permission > that you can only have granted to you if you are signed with the same > certificate as the core platform code. " > > So it's not a matter of submitting a patch, it's functionality which > will never be available to third party apps unless they come to an > agreement with the carriers. > > The crux of my argument is on an open platform why should developers > have to start petitions, create forks, or try to get carrier support > just to access functionality which is already available and in use by > bundled applications but access to it by third parties is blocked by design? > > Al. > > -- > Al Sutton > > W:www.alsutton.com > B: alsutton.wordpress.com > T: twitter.com/alsutton --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
