Android is a lot more free than iOS, but there are limits. We need to break through those.
At its birth, Android was the horizontal and open solution to the problem of Apple's vertical and closed silo. On Android, hardware makers and software writers could build devices and apps, free to operate outside the walls of any vendor's closed garden.
This was fine, as long as we ignored the closed and vertical natures of three controlling forces in Android's market space: 1) mobile-phone companies; 2) Google's main business, which is advertising; and 3) every e-commerce vendor, each operating its own silo. So let's visit those, in order.
Before Android standardized a single popular platform for smart mobile devices, the phones we got were co-silo'd by partnerships between phone makers and phone companies. Back in the early 2000s, I sat in a meeting where a parade of software developers presented ground-breaking ideas to Nokia, which had invested in a number of those same developers. At the end, one of the Nokia people explained that these were all interesting ideas, but that the company already had worked out plans for features to be rolled out during the next several years on the company's phones, in partnership with the carriers. This explained why, for example, my Nokia E62 lacked the Wi-Fi capability of the otherwise identical Nokia E61 (http://en.wikipedia.org/wiki/Nokia_E61). The E62 was built for carriers in the US, while the E61 was built for various European carriers. If AT&T didn't want Wi-Fi on the E62, it wouldn't be there.
We can thank Apple for driving a much harder and better bargain with AT&T than any other mobile-phone maker ever did. And we can thank Google for making sure that the smart mobile device market had a white-box operating system, so its hardware base could be as broad and generative as possible.
But those moves did not change the nature of phone companies, or our dependency on them. Back when JP Rangaswami was Chief Scientist at BT (and I worked for him there as a consultant), he observed that the core competence of phone companies is billing, not telephony. This is the biggest reason (among many others) why no phone company ever would have welcomed, much less created, the Internet. After all, there is nothing in the Net's protocols that welcomes, much less creates, billing opportunities. But today most of the data paths between mobile devices and the rest of the Internet go through phone company connections, and those connections are built for billing. This is done through "plans" for data usage. In some cases (for example, Sprint in the US), there are plans that allow unlimited usage. But in most cases, customers take a plan that obligates them to pay for some number of MB or GB per month, with additional charges for going over "caps". While phone companies need to make money by charging for services, it's an open question whether charging for data usage is the best, or the only, billing choice. It's just one that comes easily to a business that's already built to charge for minutes and text messages (the latter of which cost nothing on the open Internet).
Mobile phone systems are also walled in other ways the open Internet is not. For example, most data plans work only in the country where they are bought. Cross a national border and you risk "bill shock" for data use, which is charged at a much higher rate, even if you use the same company's wireless connections. While this looks like a bug to customers, it looks like a feature to the phone companies—and also to governments that enjoy getting a slice of the action and never liked the borderless Internet anyway.
Then there is the video issue. According to Lowell McAdam, CEO and Chairman of Verizon, video already makes up for half the data traffic on his company's wireless network, and will reach two-thirds by 2017. Thus, the Internet is being turned into a distribution system for "content". In terms of market power, content producers and distributors are sure to bias the growth paths of developers and their offerings, including Google and Android.
Back when Google began, in the late 1990s, advertising was barely imagined as a business model. In fact, Sergey Brin and Larry Page, Google's founders, initially were opposed to advertising. But since then, Google has become the largest company in the on-line advertising business, and advertising is the largest percentage of Google's revenue base.
Most of that advertising is not of the old Madison Avenue kind, which mostly sent brand messages out over print and broadcast media. Most of on-line advertising today, including Google's, is descended from direct marketing, which is descended from direct mail. It is meant to be personal, and it is guided by data provided through personal use, whether those persons like it or not. While Android does provide choices about privacy protection with each app one installs, users have little if any control over what happens to personal data that gets passed on to third parties, such as data brokers and analytics firms.
Lately the tide has been turning against privacy compromises and abuses by the on-line advertising business and the apps and services supported by it. Although Google takes a stronger moral stance on behalf of personal privacy than do many other on-line advertising companies, the fact remains that most users of Android phones and tablets are Google's consumers rather than its customers, which means those consumers are the product being sold to Google's actual customers, which are advertisers. From Steven Levy's book In the Plex: "We don't monetize the thing we create", Andy Rubin says. "We monetize the people that use it. The more people that use our products, the more opportunity we have to advertise to them."
Android phones also come defaulted with a pile of Google apps, placed in privileged positions in the phone's app directory. This does not sit well with Google's competitors. On April 9, 2013, Fairsearch, a coalition that includes Microsoft, Nokia and Oracle, filed a complaint with the European Commission against what it called "Google's anti-competitive strategy to dominate the mobile marketplace and cement its control over consumer Internet data for on-line advertising as usage shifts to mobile", adding "Google is using its Android mobile operating system as a 'Trojan Horse' to deceive partners, monopolize the mobile marketplace, and control consumer data". That's a bit hyperbolic, but I believe they have a case.
For our purposes in the Linux community, the main thing at issue is bias in the evolution of Android and the apps that run on it. As long as advertising remains Google's main business, and Android remains a Google project, it will be hard to keep a bias toward advertising's imperatives from having an influence.
In 1995, my wife asked a question so profound that it has haunted me ever since: "Why can't I take my shopping cart from one site to another?" The answer is that every e-commerce site is a silo with its own shopping cart, its own cookies for visitors, its own pile of visitor data, and its own silo'd relationships with visitors and customers. Nearly two decades have passed since then, and the situation hasn't changed. In fact, it is now much worse. All of us doing business on the Net need to maintain up to hundreds of different login/password combinations, and our relationships with vendors are as silo'd as they ever were. The off-line world also is infected by the same urge to entrap visitors and customers, which is why it's no coincidence that "loyalty programs" requiring that we carry around separate cards and key tags for every store chain, also began to take off in the mid-1990s.
The problem here is summed up by one of my favorite slides, by Phil Windley. It says this:
History of E-Commerce
1995: Invention of the cookie.
Cookies are a convention of client-server computing. While client-server has proven to be a handy way to build the on-line world, it forecloses countless opportunities that can be seen only from the client's side—when the person there isn't being a client. We still don't have the shopping cart we can take from site to site because we can't imagine doing that inside a world where we're always the submissive party and never the dominant one. Or even an equal. Sure, we are free to run our own servers if we like, but that answer doesn't help. In the world of e-commerce, we are merely clients, rather than human beings.
Far more can be done when we are free and independent than when we are captive and dependent. And that's the rub here. In spite of all the good Android has done for us as developers and users, too much of what we can do is still trapped inside the walls of captors on which we depend, starting with Google.
We need to start thinking and working outside the boxes that phone companies, Google and client-server-based e-commerce have built around us. Can we break out of those boxes and still be on Android? I don't have the answer, but I am working on it. Hope you are too.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide