The Business of Code, The Code of Business

This post is part of the Who's @ Google I/O, a series of blog posts that gives a closer look at developers who'll be speaking or demoing at Google I/O. This post is written by Albert Wenger, partner at Union Square Ventures (and still enjoys writing code!). Albert will be speaking alongside others in venture capital on a panel at Google I/O.

Reading the Google Code blog, it is hard not to marvel at the fundamental transformation that is taking place in the business of code. By the business of code, I mean the economics of developing and selling software. My first exposure to the software business was as a teenager in Germany some twenty five years ago. Driver's education there is quite expensive because one has to take many mandatory lessons. After all, once you have passed you get to drive on the Autobahn, which, to this date, has long stretches without a speed limit! I thought I was being clever by agreeing to write software for a driving school in exchange for free lessons. It turns out the clever one was the owner of the driving school who turned around and sold the software to several other schools.

So what would it have taken for me then to become an ISV (independent software vendor), other than actually having the idea? These were the early days of PCs. I would have had to spend a lot of money on marketing and a lot of time on in-person sales and on-premise / telephone support. Most ISVs at the time grew locally for that reason and it was not uncommon to have highly fragmented markets with literally dozens of different vendors. As the software would have grown past the very simple initial functionality that I had created, I would have had to write pretty much everything I needed myself. Need billing? Write a billing module. Need asset tracking? Write an asset tracking module. The marketplace for components evolved only much later and was almost as fragmented as the ISV market.

This situation persisted until quite recently. In fact, in 2003 I spent a year getting to know the market for software for trucking companies in the US (Why? That's a long story). That market still had essentially the same characteristics: highly fragmented, regional customer bases, and almost 100% monolithic custom systems.

Since then, the situation has changed dramatically. Today, creating new software means focusing on what the unique contribution is that one wants to offer and figuring out how to integrate with everything else. Need a spreadsheet? Use Google Apps. Need telephony? Use Twilio (disclosure: Twilio is a USV portfolio company). Marketing can happen on the web through keyword advertising and, better yet, SEO and customer sharing. For many solutions, even sales can be entirely web-based (enter a credit card!). Support can happen over the web and often users can support each other through community. Add cloud computing to the mix and you eliminate the fixed cost that was such a high barrier to entry in the early days of the web (I remember the extraordinary bills for servers and bandwidth in 1999!).

All of this has made it possible for small teams to create big successes. It is amazing what a few great coders can do, leveraging all the services that are now available. It is,however, not just the cost side of the business of code that has changed dramatically. Competition has gone global. Someone in a faraway place can create a system, and it is instantly available everywhere. The days of the profitable, regional ISV business are over. The source of competitive advantage has also shifted. In the past, if your solution had better features, you could land a sale even against a competitor that had more customers. Now, better features don't mean that much if the larger competitor has built a network effect into their business. Imagine trying to start a LinkedIn or Salesforce competitor with better features. So the very same forces that are making it much easier to get started are making it much harder to build a successful and sustainable business.

Does that mean that there will be fewer opportunities going forward? Maybe. But there is a strong countervailing force that is creating important new opportunities: the code of business is also changing. By the code of business, I mean how companies and industries (and even societies) are organized. At Union Square Ventures, we are convinced that over time, the Internet will transform most, if not all, industries as much as it is changing the software business. This has started with the media industry, where after years of prediction of change we are now seeing massive shifts.

The reason that the code of business will change is that much of it is based on historic constraints on the bandwidth and latency of information flows. For instance, a command-and-control type hierarchy is still at the heart of (almost) all large corporations. Information flows up the hierarchy with middle management in charge of aggregating information flows. Commands then flow down with middle management translating into finer grained actions. This basic structure dates back to a time of messengers and telegraphs. Corporations are slowly shifting away towards more of an Internet architecture of "small pieces, loosely joined" -- but in many cases the end state may mean that the "pieces" are independent, small companies instead of units of a large company.

These changes will take a great deal of time (decades) because existing structures have a ton of inertia. Far more people tend to be interested in preserving the status quo than in making radical changes. Also, when a whole system needs changing, it is often difficult to get there one piece-at-a-time because all the components need to fit together. But as they start to occur in other industries, the opportunities will be massive. To give just one example, consider education: the size of the textbook industry alone in the US is estimated at $7 billion annually. This is a pure content business ripe for disruption.

Enough reading -- time for everyone with a transformative idea to start coding!

By Albert Wenger, Union Square Ventures and Continuations.

Registration for Google I/O 2010 is now closed

This year's conference is now sold out, which means we'll be seeing over 4,000 of you on May 19-20 at Moscone West! For those of you who can't join us in person, video recordings of all sessions and keynotes will be available on YouTube following the conference.

Continue to follow us on Twitter for updates on sessions, speakers and the Sandbox. We'll also continue posting updates and Google I/O-relevant content on this blog.

By Joyce Sohn, Google Developer Team

SCVNGR and QR codes in location-based mobile gaming

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Seth Priebatsch, Chief Ninja of SCVNGR, who's creating a mobile game for the conference.

SCVNGR is a platform for quickly and easily building location-based mobile games. Each game is all about doing challenges at places. Go here and take a photo, go there and solve this riddle. You happen to be at this coffee shop? Awesome! Try this challenge and earn a couple points! SCVNGR powers games for all sorts of institutions ranging from Princeton to Harvard to the Smithsonian Institutes to SIGGRAPH and even the U.S Navy.

If you're attending Google I/O this year, you'll get to try out our mobile game at the conference! (Don't forget to bring your Android phone, if you've got one!) I'm not going to give it all away here, but I do want to talk about one of the especially cool features that we're rolling out using some neat Google APIs.

One of the biggest challenges that our game-builders face is how to build location-based challenges that truly verify the user has actually made it to the right location. There are some non-technical solutions to this problem, such as creating riddles that require the user to be there to solve them (i.e. what is the third word on the fourth line of the plaque on the back wall) or taking photos which are then verified manually by the community or the game developer themselves.

We've also looked at a number of more technical solutions. The most obvious being to take the geo-tagged coordinates of each of the locations with a game and then use GPS to ensure that the player is within a certain radius of the location. Unfortunately, GPS verification has issues when the locations are indoors (as many are) and can vary greatly in accuracy across difference devices.

A new option, one that we're launching in a couple of weeks, uses QR codes planted at locations within the game-board. Players must scan these QR codes to verify that they've made it to the right spot. We're using the Google Charts API as an easy way to programmatically generate QR codes. Of course, generating and planting the QR codes is only half of the equation. You've also got to be able to decode them from the phones during the game. We experimented with a couple of options as to how to best achieve this.

Our first thought was to simply have the players snap pictures of the QR code which we'd then post back to our server, decode and respond with whether or not that was in fact the right QR code (or a QR code at all). The benefit of this solution was only having to utilize one QR code processing library for both our iPhone and Android applications. But we ran into a couple issues right up front:

1. The time cost incurred by having to transmit a reasonably high-resolution image to our servers.
   
2. Most players aren't very good at taking pictures of QR codes. They move the lens of the camera very close and snap the picture. (It's actually best to take the picture from 12-24 inches away to enable the camera to focus sharply on the QR code.) This led to a high-number of failed submissions before we were actually able to recognize a valid QR code.

Add all this up and it created a pretty poor game-play experience.

So we turned to the ZXing project (pronounced Zebra Crossing) which is an open source barcode processing library written in Java and highly suited to the Android environment. Running the ZXing code right on the device rid us of the time-delay introduced by transmitting images to the server. But we still had the issue of the high-fail rate of the user snapping unsuitable images. Rather than trying to implement any form of "auto-scanning", we've chosen to simply grab images from the camera every 1/8 of a second or so, scan them and stop the process once a QR code is recognized.

As for the iPhone, ZXing has an objective-c port for the iPhone, but in order to grab images in real-time from the camera, you'll have to use a private API call for iPhone OS 3.1. Luckily, Apple has officially authorized its public usage until it's made public.

We're hard at work integrating QR codes into the great game that we're building for Google I/O and we hope you'll get a chance to play. The I/O team will let you know when the game is ready! The SCVNGR team will also be there in person, so please come by and say hello! We'd love to get your thoughts on the game or just chat about some of the Google APIs that we've used within SCVNGR.

By Seth Priebatsch, Chief Ninja of SCVNGR

Google PowerMeter API introduced for device manufacturers

Today we're excited to introduce the Google PowerMeter API on code.google.com, for developers interested in integrating with Google PowerMeter. This API will allow device manufacturers to build home energy monitoring devices that work with Google PowerMeter. We're launching this API in order to help build the ecosystem of innovative developers working towards making energy information more widely available to consumers.

In today's launch of the API on code.google.com we are highlighting the core design principles towards integrating with Google PowerMeter. In particular we outline the underlying data model and the accompanying protocols to ensure that Google PowerMeter provides consumers access to their energy consumption with utmost care in maintaining the user's privacy and control on access to the information. We also highlight, with code samples and client implementations, how to easily start building your PowerMeter-compatible device.

Tune into our blog and subscribe to our notification list for announcements on upcoming developments. We are thrilled to bring together a rich framework to help more developers integrate with Google PowerMeter with our open, standards-based API.  We are looking to expose expanded features of this framework to the developer community in the coming months.

Finally, we want your feedback! Ask questions, suggest topics, and share your stories. You can do this at the Developer Lounge section of the Google PowerMeter forum.

We hope you join us for the ride ahead.

By Srikanth Rajagopalan, Product Manager

Mark your calendars for Google Code Jam 2010!

If you're reading this post, we know your passion is coding. You thrive when given the opportunity to tackle a challenge, and enjoy the rush of applying your knowledge and creativity to approach a problem. Once solved, there's nothing like the satisfaction that comes from knowing you've accomplished something great.

That's why we are excited to announce Google Code Jam 2010 to the true die-hard coding fans. Google Code Jam, powered by Google App Engine, is our annual programming competition, where thousands of coders around the world attack algorithmic problems in several 2.5-hour online rounds. If you make it through the first four rounds, you'll be flown to our on-site finals, to be held for the first time at the Google office in Dublin! Once there, you will compete with 24 other top coders for the $5,000 first prize -- and the coveted title of Code Jam champion.

We don't want you to miss out on any of the action, so we are announcing some important dates for Google Code Jam 2010. Mark your calendars:

Wednesday, April 7, 2010 | 19:00 UTC | Registration Begins
Friday, May 7, 2010 | 23:00 UTC | 24-hr Qualification Round Begins
Saturday, May 8, 2010 | 23:00 UTC | Registration Deadline & 24 hr Qualification Round Ends
Saturday, May 22, 2010 | 1:00 UTC | Online Round 1: Sub-Round A
Saturday, May 22, 2010 | 16:00 UTC | Online Round 1: Sub-Round B
Sunday, May 23, 2010 | 9:00 UTC | Online Round 1: Sub-Round C
Saturday, June 05, 2010 | 14:00 UTC | Online Round 2
Saturday, June 12, 2010 | 14:00 UTC | Online Round 3
Friday, July 30, 2010 | Google Office - Dublin, Ireland | Onsite FINALS

In the meantime, visit the Google Code Jam site and try out some of the practice problems so that you'll be ready to go once we kick off the qualification round. Hope to see you in Dublin on July 30th!

By Igor Naverniouk, Software Engineer

Introducing Google's DoubleClick For Publishers API

Today, we announced the next generation of our ad serving technology for online publishers, the new DoubleClick for Publishers (DFP) from Google. We are pleased to announce that the new version of DFP comes with a modern API that enables publishers and third-parties to customize and extend the product.

The new API is available to publishers who use DFP, as well as to third-parties and vendors who would like to build applications on top of DFP. A growing community of developers are already working on sales, order management, workflow and data visualization tools. We've incorporated feedback on the existing DART for Publishers API and believe the new API is a significant step forward. It uses SOAP, a standard and widely-adopted messaging technology that uses HTTP requests to transmit and receive XML data between your client and our servers. This means you can use it with virtually any programming language of your choice. We have a wealth of public documentation available online and there are numerous code samples and client libraries ready for you to download.

To learn more about the new API, there are a few places to get started:

• The DoubleClick for Publishers API blog:
  http://doubleclickpublishersapi.blogspot.com/


• The Google Code site that hosts all of the documentation for the new API:
  http://code.google.com/apis/dfp


• The Google Groups forum where we provide support and where you can provide feedback to us:
  http://groups.google.com/group/google-doubleclick-for-publishers-api/

We are looking forward to working with you and seeing what you build!

By Adam Rogal, DoubleClick For Publishers API Team

Who's @ Google I/O: all things Google Web Toolkit

The Google Web Toolkit (GWT) team had an exciting 2009 -- ending the year with a Campfire One where the team announced the release of GWT 2.0 with Speed Tracer. Developers are quickly adopting GWT to build compelling apps in the browser, and we're excited that we'll have the following companies demoing their applications and talking about how they leveraged GWT (and other Google technologies) in the Developer Sandbox at I/O:

Clarity Accounting, Dimdim, DotSpots, Entrinsik, Hydro4GE Inc., JetBrains, Lombardi, Media Beacon, RedHat, Rosetta, SAS, and StudyBlue.

In addition to developers from these companies, we'll also have Google engineers in the Sandbox, talking about how our internal teams have used GWT to build products like Google Wave.

And members of the GWT team will be hosting a number of advanced sessions at Google I/O. Here's a quick preview of some of the sessions (there are 4 more on the I/O website):

GWT + HTML5 can do what?!

How can you take advantage of new HTML5 features in your GWT applications? In this session, we answer that question in the form of demos -- lots and lots of demos. We'll cover examples of how to use Canvas for advanced graphics, CSS3 features, Web Workers, and more within your GWT applications.

Architecting for performance with Google Web Toolkit

Modern web applications are quickly evolving to an architecture that has to account for the performance characteristics of the client, the server, and the global network connecting them. Should you render HTML on the server or build DOM structures with JS in the browser, or both? Bruce Johnson -- one of the founders of Google Web Toolkit -- will discuss this, as well as several other key architectural considerations to keep in mind when building your Next Big Thing.

GWT Linkers target HTML5 Web Workers, Chrome Extensions, and more

At its core GWT has a well-defined and customizable mechanism -- called Linkers -- that controls exactly how GWT's compiled JavaScript should be packaged, served, and run. Matt Mastracci of DotSpots will discuss how to create linkers and explains some of the linkers we've created, including a linker that turns a GWT module into an HTML5 Web Worker and one that generates an HTML App Cache manifest automatically.

Architecting GWT applications for production at Google

For large GWT applications, there's a lot you should think about early in the design of your project. GWT has a variety of technologies to help you, but putting it all together can be daunting. This session walks you through how teams at Google architect production-grade apps, from design to deployment, using GWT.

If you're a GWT developer or considering using GWT for your next project, we hope to see you at Google I/O! It'll be a great place to meet and chat with other engineers, including the team behind Google Web Toolkit.

To learn more and to sign up for Google I/O, visit code.google.com/io.

By Joyce Sohn, Google Developer Team

Announcing Google Chart Tools

A good chart can tell a story, such as depicting when you get home on Saturday night by plotting your tweet patterns along the week.

A good chart can take an elusive concept and clarify it in a visually appealing manner. This ingenious XKCD strip uses a pie chart, a bar chart and a recursive scatter plot, to demonstrate the concept of self description.

Whether you need a simple line chart, an interactive Geo Map or a complex Motion Chart , Google can help you add live charts to your web page using our Chart and Visualization APIs. Both of these APIs are free and simple to use, however they each have distinct advantages:

1. The Chart API provides Image Charts which are rendered by a Google chart server in response to a simple URL request. Image Charts are fast to render and can be easily emailed and printed. In addition to the extensive gallery of charts, this server now also provides dynamic icons, QR codes, and math formulas.

2. The Visualization API provides Interactive charts which are rendered on the browser using a Google developed JavaScript library. Interactive charts trigger events, providing tool-tips and animations. In addition to a rich gallery of charts, this tool can also read live data from a variety of data sources such as Oracle PL/SQL or Google spreadsheets.

We have discovered that developers occasionally need some help in navigating between the many options and distinct advantages of Image Charts and Interactive Charts, and therefore decided to bring the two APIs under one new framework which we call the "Google Chart Tools". We've accordingly renamed the APIs to Image Charts API and Interactive Charts API and created a simple side-by-side comparison page which you might find useful in choosing which chart tool is better for you.

Image Chart: Oceans of the world

Interactive Chart: Oceans of the world

We hope to meet you in person at Google I/O this May. In our Google Chart Tools I/O session we plan to present many of our new features including dynamic icons, which helped us plot our version of the recursive XKCD chart below:

By Michael Fink, Google Chart Tools team

Building Apps on Google Apps? A new blog just for you

We recently launched the Google Apps Developer Blog for developers interested in building applications that leverage Google Apps. This blog will cover topics of interest to Google Apps developers building applications on top of Google Apps, integrating with them or utilizing the APIs.

Don Dodge will be the editor and a frequent contributor to this new blog. Don is a Developer Advocate at Google helping developers build new applications on Google platforms and technologies. Don has been a startup evangelist at Microsoft and is also a veteran of five start-ups including Forte Software, AltaVista, Napster, Bowstreet, and Groove Networks.

You can follow the team's updates on Twitter, too – follow @googleappsdev – and, while you're at it, stay tuned to updates from the Google enterprise team at @googleatwork.

By Mike Marchak, Google developer team

Who's @ Google I/O: spotlight on Social Web (including Buzz!)

Following on the heels of today's announcement on Buzz, we're excited to bring you the latest on all things social at Google I/O, starting with a session on Buzz APIs and a new panel session!

What's the hubbub about Google Buzz APIs?
Google Buzz is a new way to share updates, photos, videos and more, and start conversations about the things you find interesting. In this session, we'll take a deep dive into building with the Buzz APIs and the open standards it uses, such as ActivityStrea.ms, PubSubHubbub, OAuth, Salmon and WebFinger.

Where is the social web going next?
With the advent of social protocols like OAuth, OpenID and ActivityStrea.ms, it's clear that the web has gone social and is becoming more open. Adam Nash (LinkedIn), Daniel Raffel (Yahoo), John Panzer (Google), Lili Cheng (Microsoft), Monica Keller (MySpace), and Ryan Sarver (Twitter) will discuss the importance of such emerging technologies, how they've adopted them in their products and debate what's next.

Here are additional sessions that'll give you a deep dive into the emerging technologies and standards that will help you create a more engaging user experience for your web applications and sites, and enable a people-centric web.

• Optimize your site with Friend Connect, Facebook Connect, Twitter, & more


• iGoogle developer portal and tools


• Make your application real-time with PubSubHubbub


• The open & social web

You'll also have the opportunity to meet developers from the following companies in the Social Web pod of the Developer Sandbox: Atlassian, eBay, IBM, LinkedIn, MySpace, Ning, Playfish, Yahoo!, and Voxeo. They'll be demoing their social apps, talking in-depth about integrating with various Google technologies, answering questions, and chatting with attendees.

To learn more about and register for Google I/O, visit code.google.com/io. We add new sessions and content to the I/O website each week, so follow @googleio on Twitter to keep up with changes!

By Joyce Sohn, Google Developer Team