Mac Slocum

Wired is one of the few magazines I read cover to cover. It consistently exposes me to new ideas and topics. For that, I'm grateful (and a longtime subscriber).

But when it comes to the iPad, I really don't understand what the Wired crew is doing.

Design-wise, Wired's iPad demo looks beautiful. Take a look:

Yet, reading over this analysis piece by Reuters' Felix Salmon, I'm dismayed to see a return to the days of silos and closed content. Here's how Salmon puts it:

Wired doesn’t want to allow simple links in ads or stories which would open up in the iPad web browser, since opening the browser means closing the Wired app. Instead, web links will open in a pop-up window within the iPad app, which then gets closed, returning you to the position in the magazine that you came from. The whole ethos is a magazine-like one of a closed system with lots of control -- the exact opposite, really, of the internet, which is an open system where it’s very hard indeed to control the user experience. [Emphasis added.]

This type of thing might work on the Kindle, where the "browser" is experimental (for now) and web hooks are limited. But the iPad is an Internet device and limiting web-based functionality from within an app -- even a very pretty app -- is counterintuitive. Web links should open in a web browser. Preferably a very good, very fast web browser, not those lumbering browser wannabes built into some iPhone apps. And whether I return to the app is up to me, not the publisher. I'll be back if the content is valuable. You just have to take my word on that.

Moreover, remember the early days of the web when designers dumped text into GIFs so they could lock down the look and feel? They just had to have control. And remember how that turned out? Trapping text in graphics is a big usability no-no. In time, we'll look at closed iPad apps the same way. It's backwards.

Digital content, like water, will always find a path to freedom. You lock it down, someone else will open it up. That's why the Wired iPad app -- and other offerings from publishers accustomed to silos -- should get ahead of the curve now. These apps need to offer more embedded links, more web hooks, and more opportunities to share. Designers can still create beautiful layouts. The user experience can still be unique. Advertisers can still be wooed. But the content itself needs to be connected to the web because it's being accessed through a web device. So why not expedite the inevitable and turn connectivity into an asset from the onset?

Tim O'Reilly and DeWitt Clinton are both experimenting with Google Buzz as a long form -- well, longer form -- publishing tool. It's an interesting adaptation for Buzz, and I think they're on to something.

Here's why: Blogs are great for getting people to a site. Twitter is great for tossing around short-form ideas and quips. Facebook is great for talking with a defined community.

But blogs are not inherently social. They try to be, with comments and RSS, but they're still built in silos. Twitter is unbelievably social, no doubt about that, but it's also shorthand. It's very hard to have an engaging conversation in 140 characters. And Facebook is like a ping-pong match: lots of back and forth excitement, but very little substance.

Buzz could be the missing link here. It's a hybrid option that's not particularly good at being a blog, or a microblog, or a social network, but it's a good tool for starting conversations and noodling on topics. (Keith Crawford picked up on this early on.) Tim noted during a recent conversation that Buzz is a throwback to blogging's early days, when informal posts were the norm.

Buzz in many ways occupies the same domain as Tumblr and Posterous. All of these services let you dip a bucket in the social/content stream and pour the catch into your own trough. But Because Buzz is constructed in a social environment, as opposed to a publishing environment, it's a bit more natural to share all that conversation and information.

A lot of people just like to get on with it, which is why Twitter and Facebook will always be more popular. And I'm not saying -- nor am I even hinting -- that blogs are dead. Far from it. You need a hub for all those social media spokes, and blogs make great hubs. DeWitt Clinton, in that same Buzz update, actually predicts a time when posts and comments from blogs, Buzz, and other networks will "flow seamlessly back and forth between them, such that the syndication will no longer be in only a single direction, but rather a network of threads woven together." That functionality is still a ways off (and I hope it arrives sooner rather than later), but in the interim it looks like Buzz has opened yet another content channel; a social space where you can toss an idea into a pool of willing conversationalists and see what happens.

One last thing ... because a blog post lauding Buzz for its conversation tools carries a hint of hypocrisy, here's my own attempt at a related Buzz conversation starter.

The debate over HTML5 vs. Flash is great for comments and page views, but all that chatter obscures the bigger issue: Should developers and designers invest in HTML5?

According to Eric A. Meyer, an author and HTML/CSS expert, the answer is a definitive yes. In the following Q&A, Meyer explains why HTML5, CSS and JavaScript are the "classic three" for developers and designers. He also pushes past the HTML5 vs. Flash bombast to offer a rational and much-needed comparison of the toolsets.

HTML5's feature set

Mac Slocum: How is HTML5 different than HTML as we currently know it?

Eric Meyer: It's really the HTML we're all used to plus more elements. But that's the 80/20 answer. HTML5 adds new elements for things like sections of a document and articles, and figures and captions for figures. So it covers things that a lot of us do all the time, like create <div class="figure"> and then <p class="caption"> inside of that to go along with an image. Now there's just an element called "figure" and you insert an image and you have an element after that called "caption."

There's been an attempt to look at what people are doing. What class names are people using over and over again? What structures are they setting up over and over again? Because HTML doesn't have elements that directly address those.

The HTML5 spec also attempts to very precisely and exhaustively describe what browsers should do in pretty much any given circumstance. Older HTML specifications would simply say: "These are the elements. These are the attributes. Here are some basic parsing rules. Here is what you're supposed to do if you encounter an error." HTML5 has these really long algorithms that say: "Do this, then this, then this, then this. And if you hit a problem, here, do this other thing." There's a lot of debate as to whether that's even a good idea. But if the vision that's encoded in those algorithms is brought out -- I'm not saying it will be, but if it is, then browsers will be a lot more interoperable.

But that's the base level answer. As you push further into the more obscure corners, then the answer to "how is HTML5 different?" becomes much more complicated.

MS: Is HTML5 becoming a full-fledged development environment?

EM: I don't see it stepping forward into full-fledged programming. But I do see it pushing HTML forward so that it's a better foundation for web apps. That's one of HTML5's primary goals. There are sections of it that are devoted solely to how to deal with web application environments.

The thing that's most directly applicable to making HTML more web-application friendly is the attempt to include what's known as microdata. That's semantic information and little snippets of data that can be embedded directly into what we think of as pages right now. But these can become the views a web application presents. It's the kind of stuff that we put in cookies now.

But HTML is not getting for loops or switch statements. That's going to stay with JavaScript. In that sense, no, HTML is not becoming a programming language.

What developers and designers need to know about HTML5

MS: What skills do developers need to take full advantage of HTML5?

EM: Developers need to know HTML5. They need to know JavaScript and they need to know CSS. That's the classic three.

MS: How about designers?

EM: Designers need to know mark-up. They need to know HTML5. They need to be able to write CSS and understand web layout. And they need to have at least a decent grasp of what JavaScript does. I don't necessarily insist that everyone who ever touches the web be able to write their own web app by hand, but designers should understand how JavaScript works.

There are a lot of people who call themselves web designers who are really just designers who put their designs on the web. And there's nothing wrong with being just a designer. But they're not necessarily web designers. They're visual designers. There's a difference.

MS: Would you recommend starting with web development skills and then adding Flash and others later?

Yeah. Make that your grounding and then add things to it if you like. You're making a very dangerous bet to not have web tools at your disposal. The developer should be able to do web work. And it's not a bad idea to add Flash to the tool belt.

HTML5 vs. Flash: A rational comparison

MS: Without getting into the "Flash killer" stuff, how does HTML5 compare to Flash?

EM: HTML5 itself and Flash are vastly different. They have different things that they're trying to do. But the HTML5 plus CSS plus JavaScript package is more. I think that's an easier comparison to make to Flash because Flash is supposed to be this total environment. You can put things on the screen and you can script it and you can define interaction. And HTML5-CSS-JavaScript lets you do that as well.

We got to the point a couple of years ago where the HTML-CSS-JavaScript stack can technically do just about anything that the Flash environment makes possible. It's just a lot harder at the moment to do that in HTML5-CSS-JavaScript because Flash has about a decade's head start on authoring environments.

There are a number of people, myself included, who have been observing for a while now that the current web stack feels like Flash did in 1996. Look at the canvas demos, for example. The canvas demos we're seeing now are totally reminiscent of the Flash demos we used to see in the '96 era, where it was like: "Hey, look! I have three circles and you can grab one with a mouse and flick it. And then it bounces around the box and there's physics and collision and animation and they're blobby and woo hoo."

MS: What's your take on plugins? Are they inherently inelegant?

EM: That's been my feeling for a long time. That any plug-in is kind of inelegant and the wrong way to be going about this. And I don't reserve that just for Flash. I really mean any plug-in. The fact that we need plug-ins to play movies has never felt right.

MS: If, for a given application, HTML5 and Flash can provide the same result, why would a developer go with HTML5? What's the motivation?

EM: HTML5 is native to the medium. It's the feeling that if we're going to do web stuff, let's do web stuff. Let's not do Flash stuff that happens to be represented in a web page. So I think that's the philosophical drive.

The technical drive, to a large degree, is that companies don't want to be beholden to somebody else. And doing everything in Flash means that they're effectively beholden to Adobe. With web technologies, the only entity that can reasonably be said to hold the keys to the kingdom is the W3C. And even if the W3C for some reason turned into "evil goatee Spock" tomorrow and said "we want licensing fees," everyone would go, "yeah, no."

HTML5 and mobile applications

MS: Does HTML5 give mobile developers more latitude? Is there benefit in developing applications outside Apple's approval process?

EM: Absolutely. No question. There are some people who have argued that the whole App Store phase is a fad. Granted, a very popular and lucrative and probably long-lived fad, but that it's still a fad.

The argument is that 10 years from now we're going to look back at rebuilding apps for every mobile device and go "What the hell were we thinking?" It's the same way kids who graduate from decent web development programs today don't understand why anyone ever tried to layout a page with tables. I've had conversations with people who literally just can't understand. Even when you explain, "Well, there was no CSS." They're like, "But surely there was something better because that's just awful."

Betting against the web is the sure losing bet of technology. Over the long-term, that's where I see things going.

Since virtually all of my work is done on the web, I've grown accustomed to granular information. Even a casual look at web traffic reveals insight. I can see the topics that strike a nerve with visitors. I can pick out new or unusual traffic sources. I can even see how usability and design influence click-throughs.

Yet, all that goes away in the real world. My parents, for example, have owned the same retail store in the same location for more than 20 years. They have strong relationships with regular customers and they're committed to their local community. Despite all this experience, many of their decisions are still based on hunches. They don't have much data and their feedback mechanisms are limited to word of mouth and occasional coupon campaigns.

But what if my parents -- or any small business owner, for that matter -- could gather hard data that showed foot traffic broken down by months, weeks, days and times? What if they could experiment with product display hot spots and analyze the sales results? What if they could entice customers back to their store with customized offers?

Mobile location services may soon make this sort of real-world analytics possible -- and not just for the big guys. Foursquare, which we recently profiled here on Radar, is already rolling out an analytics dashboard that will give business owners data about the people who check in to their establishments. That's a huge first step, and I imagine other location services will follow suit with their own analytics packages. Within a year -- maybe even six months -- we'll see a lot more discussion around local SEO and mobile-based social search. And I won't be surprised at all if mobile bar code/image scanners transform from fun fringe apps to core functionality, especially if associated data can be harnessed and analyzed. Put all this together and it feels like we're on the verge of finally scratching that real-world data itch.

Open government isn't about just one government. That's why I got in touch with David Eaves, a public policy entrepreneur and a speaker at this week's Gov 2.0 International online conference. In the following Q&A, Eaves weighs in on the state of open government in Canada. He also talks about the ironic adoption of open government behind firewalls, and he calls government's insistence on only releasing completed projects a "collectively imagined limitation."

Canada's local traction

Mac Slocum: Is open government moving forward in Canada? How does Canada compare to other countries?

David Eaves: The real successes of open government have occurred at the local level. Vancouver was the first city to adopt an "open motion," which directed city staff to start sharing data, using open standards, and exploring the use of open source software. It was the second city in North America (after Washington D.C.) to launch an open data portal. Toronto and Edmonton have followed suit. These cities all have politicians who understand the potential of open government and are willing to be champions.

Also exciting are the pockets of success at other levels. I've been speaking with the staff at Canada's Parliament buildings and they are increasingly interested in sharing Parliament's agendas, bios of MPs, bills and other data that could help citizens better understand what is taking place in the nation's capital. This is an important and exciting development.

At the provincial level, there has been very little discussion. The debate is virtually non-existent at the federal level. This isn't to say there aren't open data sets. Some federal ministries, in particular Natural Resources Canada, have been sharing geospatial data freely and openly for a number of years now. But this is an isolated exception. There is no effort to rethink policy around open data or open government at the federal level or in any province that I'm aware.

Broadly speaking, the open government movement in Canada has not penetrated governments -- and in particular the political class -- to the same degree it has in countries like the United States or Great Britain.

Federal challenges, private use

MS: What are the biggest challenges open government faces in Canada?

DE: There are several. The biggest is the lack of political leadership around this issue at the provincial and federal levels. Indeed, I know of IT vendors who have talked to key federal officials about this idea -- citing the developments in both the U.K. and the United States -- and they have been rebuffed.

In addition, the resources for advocacy in Canada are more limited than in the U.S. or the U.K. In the U.S, organizations like the Sunlight Foundation can show the government how it can be more transparent, hold the government to account on promises, and take non-machine-readable data and make it more accessible. Canada -- due to its smaller size and, interestingly, tax law -- has fewer foundations and donors who can sponsor such a project.

MS: Is there more adoption of social media and open government principles behind government firewalls?

DE: Definitely. This is an important debate that is presently taking place within government. The Canadian public service has actually led with some of the most innovative approaches, especially around the use of wikis behind a firewall. Natural Resources Canada has been drafting Deputy Minister briefing notes on a wiki, and GCPEDIA -- a MediaWiki install -- is available to any public servant who wishes to use it. [GCPEDIA is not publicly accessible -- Ed.] I just wrote an article on this very subject in the Globe and Mail.

There is, however, significant resistance. Some of it is out of lack of understanding and fear of change. But there are also those who see social media as a threat to their capacity to control an issue or area. I've talked to public servants who have been ordered -- by their bosses -- not to work on GCPEDIA. Deeply interesting stuff.

Government needs more beta

MS: Broadly, do you think government's focus on producing "final" projects hinders progress?

DE: Absolutely. Government's obsession with a "final" product is in many ways a relic of the industrial era. The idea that only a finished product can be released to the public -- a public whose needs both the private and public sector often misunderstand -- means that huge cycles are wasted, and launch times delayed, in perfecting programs and products that often don't hit the mark. Everything is a beta today because almost everything can be improved on the fly. What is saddest about this obsession with final products is that it isn't connected to what government does or the technologies. It's a collectively imagined limitation.

My sense is that the rise of social media will help spread the idea of a "patch culture." One in which citizens and public servants are more empowered to offer critical feedback and make changes on the fly.

MS: Your chapter in "Open Government" touches on the DIRECT Launcher project, which is a great example of an external, non-government initiative influencing government projects. Is DIRECT Launcher an exception? Or, do you expect to see more of this external-to-internal collaboration?

DE: I think Direct Launcher is interesting because it is both external and internal simultaneously. It is actually initiated by government employees whose code of ethics and desire to serve citizens more effectively causes them to self-organize, and to circumvent the bureaucracy they are a part of.

Sadly, I believe this is presently an exception. This is a particularly tech savvy community and so they were able to use technology to self-organize in a way that might not be possible in other government agencies. However, as people become more comfortable with online tools, I do expect this type of activity to become more commonplace. DIRECT Launcher is a fascinating example as it demonstrates how authority and accountability will change in a Gov 2.0 world. The story here isn't about how they self-organized, it's about the implications for civil service culture, processes and hierarchy.

Note: This interview was condensed and edited.

Instant access to burritos bigger than your head is the clear selling point of Chipotle's iPhone app (iTunes link). But if we put culinary convenience aside, the app itself is an interesting mix of simple design, e-commerce functionality and location tools.

I've been digging into the app for a while (digging does not equal "eating," in case you're wondering), and I found three aspects to the app that could prove instructive for developers and businesses pursuing their own mobile paths.

1. Centralization

I asked, repeatedly and from a variety of angles, for revenue information related to the app -- direct sales, percentage of total sales, etc. Chris Arnold, Chipotle spokesperson, politely declined to answer the money questions. The closest I could get was the total number of app downloads, which is currently at 600,000. And since Chipotle has around 1,000 restaurants, that's considerable overlap.

Arnold did open up about the app's integration into Chipotle's ordering and payment processes. What I found most notable in this regard is the oddly detrimental role of franchises. The Chipotle app represents a case where corporate centralization led to a relatively painless product roll-out.

Here's why: Chipotle owns all its restaurants, and Arnold credits this with allowing the iPhone app to mesh well -- and quickly -- with existing systems. "It can be hard to get all of your franchisees to participate in a new program like that, particularly if investments in technology or other infrastructure are necessary," Arnold wrote in an email. Centralization ensures the Chipotle app works at all of the company's restaurants.

Chipotle also benefitted from a pre-existing online ordering system. "If you don't have that infrastructure in place when you start your work on an iPhone app, you're going to be in trouble," said Pervasent's Stuart Williams, CEO of the development shop that handled the Chipotle app's programming. "It's certainly the case that mobile ordering follows in the footsteps of a decent web order."

2. Defining the use case

Chipotle and its development partners constructed the app with a particular customer in mind: a young, urban professional who needs to grab lunch on the go. That's not to say customers outside this very specific example are irrelevant; non-hipsters can benefit from the app as well. But this defined use case proved important during the development process because it led to functionality and conclusions. Here's two examples:

• Young professionals and iPhones go hand-in-hand, so the justification for creating the app is built in. It doesn't make sense to develop an iPhone app -- or any mobile app for that matter -- if your customers don't rely on app-friendly phones.
• Since lunch is the primary meal in this use case, that means the customer is probably visiting a Chipotle restaurant near his/her office over and over again. As such, the app asks for and remembers location on the first launch, but subsequent location look-ups have to be initiated manually. This isn't a "road warrior" app that automatically discovers nearby restaurants. It's about defined, ongoing convenience.

3. Limited options

One final observation ...

It would be tough to create a simple, easy-to-use mobile app that encapsulates the breadth of meals and ingredient variations at restaurants with long menus. A website can tackle this task, that's for sure, but the mobile experience carries unique usability issues. Something as simple as going back and forth between screens can get real clunky, real fast on a small device. Chipotle's menu, on the other hand, works well in the app world because it's uniform and limited.

"The app is designed very much around their menu," said Williams. "It's not like you could take this app and service a white tablecloth restaurant. Or even service a Subway. A really well-designed app for Subway would work different than a really well-designed app for Chipotle."

Oracle's acquisition of Sun has opened up all sorts of questions: Will MySQL get the support it needs? What will become of the MySQL community? Where should database administrators put their efforts and resources?

Ronald Bradford can answer that last question. Bradford, an RDBMS expert and a speaker at the upcoming MySQL Conference and Expo, has been guiding DBAs through key aspects of MySQL integration for years. In the following Q&A, he discusses the pros and cons of migrating from Oracle to MySQL (hint: it's not just about cost savings). He also weighs in on the future of MySQL and its community.

Jumping from Oracle to MySQL

Mac Slocum: What are the upsides to migrating from Oracle to MySQL? Is cost the major factor?

Ronald Bradford:The Oracle license cost is generally the most important factor for organizations considering migrations. Also, integration with open source LAMP products that provide many features you see today, including project management, bug tracking, wikis, blogs, and customer relationship management, are better served when all systems can communicate with the underlying data storage in MYSQL.

Newer and cheaper multi-core hardware, and a correct scale-out architecture, manages risk better then a single, large, scale-up instance of your data. Failure of 1-10 percent of your user data is far better then 100 percent failure.

MS: What are the major issues with Oracle to MySQL migration?

RB: Adequate education and skills development is the most significant and most under-budgeted cost in migration. While the cost of licensing and subscriptions is generally less for non-Oracle solutions, MySQL is not Oracle. Most organizations underestimate the time needed for staff to become proficient in a new skill, especially when they're required to maintain existing systems.

The second factor is staff pushing back against MySQL. For example, management at a top 20 website I was involved with made the decision to replace Oracle with MySQL. The technical resources, including system architects and senior DBAs, were not in agreement and they sometimes actively fought against the implementation of MySQL.

The third issue is monitoring. MySQL does not have the level of in-depth instrumentation it should. While it's integrated into existing open source monitoring products, MySQL is not always well supported by production network operations center systems.

For these reasons, slow integration with less critical systems is a successful integration model. This enables time for a comfortable and successful transition and it creates confidence moving forward.

MySQL's future

MS: What do you think will happen to MySQL once dust around Oracle's acquisition of Sun settles?

RB: Oracle has made a written commitment to invest in MySQL at the same rate as Sun for the next three years. Given the vast experience and R&D budget Oracle has given its product line, I hope more is invested in MySQL.

In the year following MySQL's first acquisition by Sun, they failed to produce advances the community would have liked. Many in the community were disappointed by the stealth release of 5.4. I suspect it will take some time for Oracle resources, processes and procedures to integrate with the existing MySQL engineering lifecycle, and it will take time before we see any future work.

I would like to see two areas of MySQL deficiency addressed: a totally integrated and online backup solution, and better instrumentation.

MS: Will the MySQL developers under Oracle build stronger bonds with users?

RB: Open-source culture is unique in comparison to commercial, closed-source products. Developers who work for MySQL now will continue to be available to alumni and the community, and I suspect they will continue to write, blog and actively present.

While there has already been a small exodus of staff from the Oracle acquisition, any restrictions between staff and open source developers will greatly hurt the community. On the flip side, it will be difficult for Oracle developers who start using and contributing to MySQL development to be more open and responsive. It's unfamiliar ground.

MS: Will work by Monty Widenius and others bring into being a larger after-market of MySQL extensions and patches?

RB: The after-market movement started many years ago when MySQL executives lost perspective on the community and focused on commercial viability. This after-market will continue to flourish. I agree with a fellow community member who recently stated that the trademarked version of MySQL will be just one variant of the overall MySQL product. There are individual products that are as good if not better then the official MySQL version. What's lacking are commercial support options and documentation.

MS: Will the varied projects that fall under NoSQL take market share from relational databases? Or will they grow in parallel?

RB: MySQL has continued to grow in the database market. Oracle and other products have also grown. That indicates a general increase in demand regardless of the specific product. I see NoSQL adding value and options to an increasing marketplace.

The NoSQL options have some great benefits, and in any emerging topology it's important to architect a solution that maximizes the strengths and minimizes the weaknesses of the products in use. Persistent or non persistent key-value stores, including Memcached, Tokyo Tyrant, Redis and Cassandra, are ideally suited for some functionality. Unstructured data being managed by MongoDB or CouchDB will be ideal in other situations.

Another key area is that of free text searching. Products such as Sphinx, Lucene and Solr are critical to a successful website or application.

The recent news that Twitter is moving to Cassandra highlights that products like these can deliver in highly available and scalable situations. It all depends on the right product for the given business requirements.

MS: You'll be speaking at the MySQL Conference and Expo in April. What are you hoping attendees will take away from your "MySQLCamp for Oracle DBAs" tutorials?

RB: It will be difficult in two sessions to provide great depth for Oracle DBAs. However, attendees will get the wealth of my 20 years of commercial experience in Oracle, MySQL and other RDDBMS products. They'll also get a methodology for how to approach MySQL from a different skills background. Attendees will be able to identify the clear strengths and weaknesses of MySQL, and I'll provide information on common pitfalls.

If I was to give a single statement that also encompasses some important content, it's this: Don't Assume. MySQL is not Oracle. Obvious mistakes in terminology, syntax and structure can be significant in the performance and best practices for using MySQL.

The outline of the four talks in my MySQLCamp for the Oracle DBA series, two of which are being presented at the conference, is available on my website.

Note: This interview was condensed and edited.

There's been plenty written about the App Store gold rush, but this is the first rags-to-semi-riches piece I've seen about the Android Market. Edward Kim, creator of the Car Locator app, saw his daily revenue jump from around $100 per day to more than $400 per day when the $3.99 app claimed a featured spot in the Market.

It's only one data point, but I'm interested in the broader implications here. Those early "there's gold in iPhone apps!" stories fueled interest in the platform. And while a lot of that iPhone excitement was later tempered by the realities of a hit-driven business, that first flush of exuberance was an important step.

If similar stories pop up in the Android universe -- legit stories, I'm not advocating lies and fabrications -- I see that catalyzing more developer interest, more competition, more refinement (something that's sorely needed in the Android Market), and ultimately, a more robust Android app ecosystem. That's a lot of "mores," I know, but after three-plus months of using an Android device, my enthusiasm for this platform continues to grow. Apps like Google Goggles and Google Sky Map are amazing. What I'd like to see, however, is broader Android experimentation by companies not named Google.

Foursquare is an on-the-rise application that blends mobile, location awareness and a clever points system that's an evolutionary leap for loyalty programs. Think coupons, but with rich data and gaming thrown in.

Dennis Crowley, co-founder of Foursquare and a speaker at the upcoming Where 2.0 conference, cut his teeth on location services at Dodgeball, a mobile/social company that was a bit ahead of its time. Google acquired Dodgeball in 2005 but shuttered it in 2009. Crowley used that early experience -- the good and the bad -- to shape Foursquare.

In the following interview, he digs into those Dodgeball lessons while also revealing Foursquare's revenue plans and the "secret sauce" that drives the service.

Unlocking growth with local offers

Mac Slocum: Did Foursquare have a slow adoption pattern at the beginning and then hit a point where growth exploded?

Dennis Crowley: It was super slow. We launched in March [2009] at South by Southwest and maybe picked up 2,500 users. It didn't take off the way we wanted it to when people got back from South by Southwest, and I think a lot of it was because the product was half-baked.

Things improved in July when we got the iPhone version fixed a little bit and we started experimenting with the specials we're doing with local businesses. Things like, if you're the mayor, you get a free cup of coffee or a free slice of pizza. Once we started that, it helped tell our story better. December is when it really started to pick up. The growth curve is absurd right now.

MS: Who is the typical Foursquare user?

DC: We don't have that in terms of metrics because we don't collect age or income information. But I can make some generalizations about it, and I think people in the 24-35 age range represent the active user base. It's younger and social and probably a little bit more urban. But it definitely extends into the suburbs. We see parents with kids using it to connect with other parents at playgrounds. We see high school students using it. We see college kids using it.

Allowing for adaptation

MS: How has Foursquare adapted since launch?

DC: Foursquare was launched almost as a response to Google turning off Dodgeball. Naveen [Selvadurai] and I wanted to build something to replace Dodgeball because there's nothing else that really works like that. So the initial functionality was built around check-in: you know where people are, and we'll be able to serve up recommendations.

But then we started thinking about the things you'd want to build on top of that platform. How about little bits of information? Tips about the place that I'm at? Or, let's use game mechanics to push people to do things they normally wouldn't do and encourage people to have more interesting experiences.

The game mechanics are the secret sauce. They keep people engaged long enough to see the interesting things that happen when they participate frequently. It's kind of like with Twitter. If you drop someone in Twitter and don't give them a reason to participate, they get bored of it really quickly. But, if you spend 10 days with Twitter, you fall in love with it. Foursquare is similar. Spend an afternoon with it, you'll say: "This is awful. I get nothing out of it." But as you start to get friends on it and as you check-in at different places, you realize complexities emerge. You see how people are using it and the content they've added. The game mechanics hold peoples' hands through the first 10 to 20 days of the service.

Foursquare's game mechanics

MS: Can you expand on the game mechanics? What aspects of Foursquare fall into that category?

DC: It's anything that happens after the check-in. So many of these location services are just about the check-in. That's the end of the story. But the candy in Foursquare is every time you check-in, you get a couple points for doing something. You can become the mayor of a place if you've been there more than anyone else. Or in an even rarer situation, you unlock a badge because you've hit certain things in a certain order, or you've unlocked a certain pattern of usage: I've been to five food trucks. I've been to five karaoke places. I'm out really late on a Wednesday night. Weird things like that.

I'm very inspired and motivated by Nike Plus. It's not a game, but there's game mechanics that make you run more. And I think Foursquare is going after the same thing. It's not a game, but the mechanics encourage you to experience things you normally wouldn't experience. I think we're just starting to scratch the surface of that space.

MS: How have users changed Foursquare's functionality?

We think of check-ins as you check-in at Yankee Stadium or you check-in at dinner. But then people use it to check-in to traffic, to check-in to the back of a cab. The playground is a good example. It's not a use case we anticipated. Parents uses it to meet up with other parents with kids. I think that's perfect. Use it whatever way you want.

MS: Are user expectations growing beyond the boundaries of what you think is manageable?

DC: I'm not so worried about the expectations because we have a really good idea of what we want to build. The thing is, we're still a relatively small team. We're dealing with scaling issues before we thought we'd have to. So, it's fine. We have to tackle those issues at some point, but we're really anxious to build because we have this great user base now. We want to push out all of these features, but first and foremost we have to make sure we keep the service up and running.

MS: Is interoperability a key to services like Foursquare? Do they have to work on as many networks as possible?

DC: We thought in silos for a while, but now the tools to share content across networks are out there. So with Facebook allowing us to easily push content into Facebook -- and Twitter doing the same thing -- it just really helps spread the service.

Fans create Foursquare mobile apps

MS: You relied on external developers to build a lot of your mobile apps. How did those relationships come about?

DC: We built the iPhone one and then we rolled the dice a bit and built an API before anything else. That turned out to be a good bet because that's how we got the Android app.

It started at South by Southwest where we met some kids who wanted to make an Android app for us. It took four months. There were three or four of them doing it in their spare time, which was great. And in a lot of ways, I think the Android app is better than the iPhone app that we built ourselves.

But we built the API first and then we did a prototype of the Android app and then we tightened everything up from both sides. And now, because there's so much interest around our Android app, we brought an Android developer in-house to help manage the open source developers.

MS: I'm really intrigued by businesses that have intentionally undefined boundaries. You nurture relationships with enthusiastic users who want to create something and then you make decisions off of that enthusiasm.

DC: Yeah, and I guess in hindsight it seems like a really brilliant strategy. But it was all accidental. We barely got that iPhone app out for South by Southwest. I think we just got really lucky that we built something people wanted to use so badly that they wanted to build apps for it.

MS: Who are your competitors?

DC: People will say we're the next Twitter. Which I don't agree with. I think we're complementary to Twitter. Or, we're the next Facebook. But we're more of a feature set to Facebook. Or, we compete with Google Latitude. Well, kind of. But Foursquare's not just about the maps. It's about what happens nearby. And then people will say Yelp is a competitor because of the interest in local businesses and the ability to leave mini-reviews behind. I feel we're right in the middle of all of these folks.

Foursquare's potential revenue streams

MS: What are you revenue plans?

DC: Well, location-based advertising just doesn't feel right. The ads aren't relevant a lot of the time. I think that's going to work eventually, but there needs to be a better short-to-medium-term solution. Our answer has been scrappy promotions that local merchants can set up with us directly. And those are tied to the metrics of check-ins. So if you've been to a place five times, or if you're the mayor of this place, we take some of the data and turn it into a reward. Things like, because you're deemed a regular, you get a free slice of pizza or a free cup of coffee. This stuff isn't changing the world, but we're finding that venues like giving these rewards out and users love getting them.

Now, is there an opportunity to monetize that little ecosystem we've created? Probably. I think it's going to take time to figure it out. We're not racing into that because we're encouraging venues to experiment with the basic tools we've created. We're seeing really interesting things come out of that. At the very beginning, it was come in and you get a free ticket to a band. Then it turned into a free cup of coffee. Then it turned into a free slice of pizza. And at this point, there's a hotel in Amsterdam that gives away a free hotel stay. There's a place in Texas that gives a free steak dinner. There's a place in New York that gives you a free bottle of wine. So we're getting to real, legitimate, interesting promotions. And it seems like it's maturing on its own.

MS: But you guys aren't getting any percentage from those transactions, right?

DC: We're not taking a cut of that yet. That's one of the things that comes up in conversation. People say we're going to kill it in the local coupon space. But I don't want to ruin it by nickel and diming local merchants.

MS: That sounds like the Twitter approach. Don't hinder growth by pre-defining revenue streams.

DC: It's a little bit. We look up to what Twitter has done. One thing that's different is we're doing experiments with brands and media companies earlier. What we don't want to do is go two years without any experiments in monetization and then, all of the sudden, have to flip a switch on. I think it's nice to have it built in from the very beginning, even if we're not generating revenue off of it.

We're in a really fortunate position. We've had calls from large media companies, from newspapers, from TV stations, and TV shows and really, everything across the board. For example, Bravo TV is now on Foursquare. They wanted to do something where people go to places featured in their shows and unlock badges that are tied back to the shows. They're going to promote Foursquare on-air. So as you're watching it at home, it's like, "next time you're out in Atlanta or New York, check-in at these places to interact with Bravo in a different way." I thought that was an awesome idea.

Different expectations for location data

MS: How does location data differ from status updates, pictures, links and other forms of shared information?

DC: I guess it's pretty clear that we're all sharing more data than we thought of sharing before. But we've heard from the very beginning at Dodgeball that sharing location gets you in trouble sometimes. Things like, "I saw you were out with such and such when you actually said you were doing this." Or, your ex-girlfriend sends you a friend request and you have to approve it because you don't want to hurt her feelings, and then she knows where you are all the time. It creates awkward interactions. There's just something different about sharing location than sharing everything else because the whole point of location sharing is to enable real world meet ups. And if something goes wrong with location share, it enables the wrong types of real world meet ups.

I think as more people start using these location services, they're going to be aware that maybe this is the one network that should just be about sharing with your real friends. The friends you would call to pick you up at the airport.

Disclosure: O'Reilly AlphaTech Ventures is an investor in Foursquare.

Note: This interview was condensed and edited.

I'm at the Tools of Change for Publishing conference this week interviewing folks at the forefront of the publishing world. I'll be posting a few videos here on Radar and you can find others at the TOC blog.

My favorite part of TOC is the energy. There's a lot of positivity coursing through the venue. There's a lot of forward thinking, too. And when you run into Richard Nash, founder of Cursor, you're encountering the embodiment of all that TOC enthusiasm. He's the anti-curmudgeon.

As you'll see in the following interview, Nash is passionate about the web's ability to connect audiences and authors with the topics that excite them. What he discusses could very well be a blueprint for future publishing businesses.