Jeff Jarvis is working on a book called What Would Google Do? Since Google just did something good for me — and for a market that needs help desperately — I thought I'd share my experience with Jeff and the rest of you.
What Google Did for me was radically improve one of the most annoying experiences in the Webbed world: registering a domain name.
Like a lot of readers here, I'm not your ordinary domain name customer. I've been registering names since 10 July 1995, whois tells me. That's when I picked up Searls.com from InterNIC. Even back then I realized (as did approximately all Web-native geeks) that the market for domain names was broken at the outset, because it caused an artificial scarcity in the midst of real abundance, and a monopoly for those privileged to work within that system.
I thought for about a nanosecond about going into that business. That's how long it takes to realize domain squatting is a scammy trade from the outset. What geek who values abundance wants to get into a game that's all about gaming a Wrong System? (Well, I know a few, but their calling has been un-game a bad system from the inside.)
So, like most folks who are not in the business, I've bought a number of domain names over the years, from Network Solutions, Register.com, GoDaddy, DomainDirect and ... I'm not sure who else. (I've also convinced Linux Journal to buy a few domain names too, some of which we've kept and some of which we've let go.)
Without exception, my experience with domain name registrars has been an upstream slog against a torrent of promotional distractions. Nobody hates white space more than a domain name registrar. (Though many run a close tie, including most advertising-supported media.)
So about half an hour ago I got a call from a guy at Network Solutions. He noted that I own giantzero.us, and told me that giantzero.com had become available. (The Giant Zero is the name of a book I'm working on, but that I'm not ready to start writing about on a website.) I asked him what it cost, and he told me $30/year or something like that — but with a price that got a lot cheaper if I bought it for five or ten years. I forget his numbers, because it didn't matter. What mattered was that I knew I could get it for less elsewhere, even without checking. But I wanted to give this guy a chance to keep and grow my business, since he had bothered to call and offer me valuable information as well as a useful service.
So I asked for his help with something else that required interaction with Network Solutions: changing an old credit card number to a new one. He told me to call back. Why wouldn't he transfer the call? It doesn't matter, because the friction was too high and the switching costs were too low. Network Solutions had its chance, and lost it.
When I got off the phone I did the easy first thing: checking withGoDaddy. Sure enough, GoDaddy offered the domain for less than $10/year. I forget the price. It only mattered that GoDaddy's deal was way better than Network Solutions'. But still, GoDaddy's search results page was thick with confusing upsells for other domain suffixes and a pile of services I didn't want.
So I typed domain name registration in the location bar of Firefox, hit return and found myself at Network Solutions. Not wanting that, I took the longcut and looked up domain name registration on Google. There I found that Google was now in the business too, offering domain name registration via Google apps. (Well, not quite. It's not clear from the Google Apps' landing page that Google is in the domain registration business. Instead you have to go here.)
So I checked on giantzero.us and found that Google offered it for $10. That's all I needed to know. From that point forward Google made the registration process simple and easy — at least compared to the other registrars. It took me seconds to do the job, and I didn't have to deal with a bunch of upselling promos and other distractions. Along the way I also got into my Google Checkout account and added my new credit card number. (Though I couldn't figure out how to kill the old one: a minor bug.)
Did I use Google just because it's a "trusted brand"? No. In fact, there are no "brands" that I trust. Sorry, marketers, "branding" is a term borrowed from the cattle industry, and I'm done being impressed that way. (And trust me, it's a taint that the trade isn't going to shake.)
I used Google because I trust them not to treat me like cattle — or worse, as a potential sucker.
This is not to say that Google's domain registration process is perfect, or that Google is being not-evil or anything fancy like that. My point is that Google offers a straightforward and uncomplicated service in the midst of a business that has needed one for the duration.
In The Big Switch, Nick Carr does a great job describing how utility computing is becoming part of business infrastructure. Google, of course, is a leader in that market development. But what Google's doing here is something else:. They're looking for large online markets where there is demand for simple and useful services, and every competitor is stuck in the 20th Century model of trapping customers and treating them like slaves. And then they execute well.
That includes Google-grade uncomplications, such as minimized text, absent graphics, and sweet peaceful spreads of white space.
It's also important to note that Google isn't giving domain names away for free. One reason is that their partner, enom.com, isn't in the free domain name business. Another is that domain names have a value north of $0. Most people are willing to trade money for value.
Note also that I didn't shop for domain names entirely on price — even though friction, switching costs and other transaction-based economics were involved. I bought this domain name from Google because I have a mutually respectful relationship with them. That relationship does not require human involvement, but it does require human values. Especially respect.
Relationships are the real frontier here, and Google is no less an explorer than anybody else. That means they too have a lot to discover. And to remember.
Back in 1969, when I was fresh out of college and living in a third-floor walk-up on North Main Street in Hackensack, I got to be friends with an older couple who lived across the hall. Their names were Hans and Illie Schmidt, and they had emigrated from Austria in the late 1930s, when it was clear that their country would fall to Hitler and the Nazis. Hans was an artist who made his living designing wallpaper (of the literal sort), but he was a brilliant guy whose knowledge and interests spanned many topics. We would talk for hours about music, chess, history and much more.
After about a year in that apartment I got a job working at a newspaper elsewhere in New Jersey, and moved away. Then one day I ran in to Hans in the parking lot of a supermarket. After exchanging pleasantries, I said something about getting together again. Hans called me on my BS. After noting that I didn't trouble to call him after we left our old apartment, he said something that burned my brain more deeply than any company's branding. He said, "Friends are so hard to make, and so easy to lose". With that, he got in his car and left. I never saw him again.
My father was with me and saw how the encounter shook me. At first I was critical of Hans. Why hadn't he called me? Why was this my fault? "It doesn't matter", Pop said. "He's right. Remember that."
Google should too. The bigger you get, the more you forget.
Doc Searls is Senior Editor of Linux Journal
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- The Secret Password Is...
- New Products
3 hours 26 min ago
- Keeping track of IP address
5 hours 17 min ago
- Roll your own dynamic dns
10 hours 30 min ago
- Please correct the URL for Salt Stack's web site
13 hours 42 min ago
- Android is Linux -- why no better inter-operation
15 hours 57 min ago
- Connecting Android device to desktop Linux via USB
16 hours 26 min ago
- Find new cell phone and tablet pc
17 hours 24 min ago
18 hours 53 min ago
- Automatically updating Guest Additions
20 hours 1 min ago
- I like your topic on android
20 hours 48 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?