Category Archives: Platforms

Death to Developer Contests

Over on his blog Microsoft’s Dan Fernandez courageously decries the frequent use of developer contests to engage developers and increase momentum for platform adoption. He counted up the number of contests Microsoft is running at the moment: it’s 18. Eighteen different ways to win cash and prizes for doing stuff with various Microsoft products.

Dan thinks this is over the top and I totally agree. When I ran the evangelism team at eBay I resisted the urge to do developer contests for the reasons Dan points out, and when I ran the Yahoo program we didn’t do any; we were more concerned with giving back to the entire community by devoting our very limited time and resources to making new products happen for developers.

Contests are like steroids for platforms. They may pump you up in the short term, but they don’t actually grow the ecosystem. Contests don’t kick off interesting and useful conversations about your platform because they put your developers in competition with each other. More importantly, contests detract resources and focus from where they’re needed.

Throughout the history of American business, the worth of marketers has been measured by the size of the marketing budget (as opposed to the results they might bring to the business). But in a world in which no platform in history has ever provided good enough documentation or code examples for its developers, there’s no excuse to do a single contest.

Mono’s “Usability Disaster” and Platform Discovery Optimization

Seeing this post from Miguel about a major cock-up pertaining to the developer download experience in Mono made me think about the platform companies we’ve been advising.

Companies often trick themselves into thinking that every developer who discovers their stuff will automatically do whatever it takes to use their stuff. But developers actually make very calculated cost-benefit choices about what technologies they want to adopt — in a world in which time is at a premium, doing nothing is always an option. If developers feel jerked around or not fully supported, they’ll turn their attention elsewhere. Certainly there are some developers who will slog through anything to get to what they want. But ultimately developer adoption is a numbers game; in our experience a sizable percentage of developers who encounter a platform will abandon it without adopting if the developer discovery experience isn’t fairly solid.

We advise our clients to own their platform discovery process from the
first pageview to the time a developer performs a download, and to
test this flow frequently. We generally recommend against permitting any part of the developer discovery process to be owned by a third party. A good example of this is Sourceforge — what they provide in terms of hosting and presence does not make up for their horrible user experience and very unfortunate practice of showing advertisements for competing products at the very moment the developer is about to hit the download button for your product.

One of the consulting products we
provide for clients with existing platform products is a developer
discovery analysis. The idea here is to go through the process of
getting up to speed with a technology platform, and then provide
recommendations to the platform provider (our client) as to what they
can do to optimize the process of developer discovery. Often the
recommendations we make are things that the client knows should be
fixed, but often our recommendations are enough to motivate them to
actually fix the problems.

This is a fairly quick way to get very detailed feedback (with screen shots, written recommendations for remediation, etc.). For start-ups that aren’t quite to the point where they can afford a product manager, it’s a cheap way to get a quick dose of help in the area of platform product management and developer user experience optimization.

Understand the Difference Between Demos and Code Examples

Lots of technology products and platforms aimed at developers — possibly the majority of them — confuse the distinction between a good demo and a good code example. A good demo looks great and dazzles your CEO and customers. On the other hand, good code examples seem to take forever to write, they never look good and they can’t be installed on the demo machine at trade shows to dazzle prospective customers.

There is a fundamental difference between a demo and a code example.
Even when a demo is available as downloadable source code, it often
doesn’t work as a good code example.

No platform in the history of platform technologies has ever devoted enough resources to creating code examples. One of the best-documented platforms I know (Microsoft’s .NET framework) still contains plenty of objects and methods that don’t have code examples anywhere. But doing this is part of the tax you have to pay if you want to have a platform. You can either do this, or you can write all the applications that you ever want to run on your platform by yourself — your pick.

Not having any documentation or code examples at all is a big problem, but using demos as code examples can be an even bigger problem because it forces developers to invest a ton of time into painstakingly picking out the code example bits from your demo. If you don’t have any code examples at all, it saves me time, because I know immediately that your product or platform isn’t ready yet and I’ll just check back in a few months.

Here are the differences between demos and code examples.

A good demo:

  • Provides information about cutting-edge or new functionality of your platform
  • Demonstrates the functionality and usefulness of your technology or platform
  • Appears presentable and is well designed
  • Can be appreciated by coders as well as non-coders
  • Is available as source code
  • Is intended to get users to adopt or purchase your product

A good code example:

  • Provides information about the existing functionality of your platform
  • Must function and run out of the box with as little configuration as possible
  • Must not have invisible or undocumented dependencies
  • Demonstrates the most granular possible piece of your platform’s functionality
  • Uses the simplest code that could possibly work
  • Does not contain code that does not demonstrate the functionality you’re conveying
  • Is written in a language that your developers are likely to want to use
  • Is subjected to the same process as the rest of your production code (including QA, source control, unit testing, versioning, etc.)
  • Is intended to get developers to adopt your product or feature

See the difference?

It is possible to create both demos and code examples economically. It happens to be one of those tasks that is a prime candidate for outsourcing, even if your company is small and your platform is not necessarily mature. We are doing both demo/prototype and code example projects for a couple of clients at the moment.

With this post I’m kicking off a new category of posts for the blog, Platforms. I’ll go back and retcon some of the old posts I’ve written on this subject into this category so it’ll all be here.

StubHub Scrapers

Link: Hannah Montana Tickets on Sale! Oops, They’re Gone

"[Hannah] Montana tickets, whose face value is $21 to $66, have been resold on StubHub, on average, for $258, the company says, and that is without taking into account StubHub’s 25 percent commission (10 percent paid by the buyer, 15 percent by the seller). None of the proceeds from the resale of tickets at inflated prices make their way back to Ms. Cyrus.

Some ticket brokers are so certain of their ability to get hold of desirable tickets that they confidently advertise tickets on these exchanges even before tickets go on sale to the public.

How do they do it? An intriguing explanation is that brokers use specialized software to make multiple online purchases of tickets, circumventing the four-ticket-per-customer limit that the rest of us must abide by."

This in many ways sounds like a replay of eBay’s early days as a platform five years ago, when the company was compelled to create a web service API with its own terms and conditions as a way to regulate rogue developers who were writing eBay applications by scraping HTML from the site. Now, StubHub (an eBay company) is running into the same thing; it can’t be a coincidence that StubHub doesn’t have its own web service API.

Static on the Dream Phone

Link: Static on the Dream Phone

"Verizon announced last month that it will open its network to ‘any application and any device’ by the end of next year.

But while Verizon’s pledge sounds promising, the language in which it is couched makes me wonder whether Verizon understands what a true open platform looks like. The announcement states that ‘the company will publish the technical standards the development community will need to design products to interface with the Verizon Wireless network,’ and that ‘devices will be tested and approved in a $20 million state-of-the-art testing lab.’ It’s not yet clear what standards developers will need to follow to write applications that work with both the device and the network, and who will control those standards.

This is not ‘open.’ It’s just a little less closed. A true open platform like the Internet doesn’t have certification of trusted devices or applications. Developers get to do anything they want, with the marketplace as their only judge and jury."

Tim O’Reilly in an op-ed in today’s New York Times makes the argument that if a developer has to ask permission to write an application on a given platform, that platform isn’t really open. This notion is one of the ten principles for platforms that I laid out in 2006 when I started Platform Associates.

As companies attempt to reap the benefits of open platforms, I’m seeing more and more situations where companies release fake open platforms — attempting to benefit from the momentum of platforms without performing the necessary activities to become an actual open platform. In Verizon’s case, one wonders what they think that "any device and any software" is supposed to mean.

Unfortunately for them, fake platform companies are also missing out on the benefits. When I’m engaging with a company that wants to provide a platform, I try to keep it positive and emphasize the benefits to openness, rather than focusing on the horrible credibility problems that happen when you say you’re open but really aren’t. For example, a lot of big companies hire teams of business development specialists to trawl for partnership opportunities. What if these opportunities simply came to you? Similarly, most companies (even very large ones) have difficulty performing all the engineering work necessary to keep every kind of customer happy. What if you gave customers the ability to do this work themselves? And so on, and so forth.

Platforms that use the term "open" without actually being open do so at their peril, but they’re also missing out on huge opportunities.

Does “Open” Really Help Developers?

I’m doing some more research on the GPhone/Open Handset stuff today. For the second week in a row, Google is evangelizing a new, "open" platform, with the promise that openness will inherently be easier to develop applications on, create a better consumer experience, and eventually solve world hunger.

Specifically, the Open Handset folks seem to be asserting:

  1. Today’s mobile platforms aren’t open.
  2. It’s a big problem that mobile platforms aren’t open.
  3. Making a platform that’s more open will foster more and better applications for mobile.

Assertion #1 is just not true.

Assertion #2 is true, but only in the sense that not being able to see at night is a problem. Unlike a lot of closed vs. open technology conundrums, "mobile" isn’t a big monolithic platform controlled by one malevolent overlord, at least not at the application layer. They’re several platforms controlled by a gaggle of overlords, some of which are less malevolent than others.

Assertion #3 is completely false, at least based on what we’ve seen so far. It must be false because there already are mobile platforms (both Linux and Windows Mobile) that enable developers to create applications without the intervention of the carriers.

Just making something "open" does not contribute to developer productivity. In fact, openness can hinder developer productivity, since it forces developers to contend with a large number of use cases that aren’t relevant to them, and it enables the platform provider to get away with cop-outs like "you can change the source code to make it do whatever you want" and "we realize our documentation isn’t great, but the source is our canonical reference".

And Java (which the Open Handset platform will be based on) is certainly not the highest-productivity development environment out there today (and I know a lot of Java developers who will agree with me there).

I’m not saying "openness" is "bad". I’m just saying that Google is assigning attributes to the notion of openness that don’t make sense. One gets the impression that this project is being done by a certain type of open-source developer for a certain type of open-source developer.

Google Makes Its Entry Into the Wireless World

Link: Google Makes Its Entry Into the Wireless World

"John O’Rourke, general manager of Microsoft’s Windows Mobile business, said he was skeptical about the ease with which Google will be able to become a major force in the smartphone market. He pointed out that it had taken Microsoft more than half a decade to get to the stage where the company now does business with 160 mobile operators in 55 countries around the world. ‘They may be delivering one component that is free,’ he said. ‘You have to ask the question, what additional costs come with commercializing that? I can tell you that there are a bunch of phones based on Linux today, and I don’t think anyone would tell you it’s free.’"

At first glance this quote looks like some spin put out by the incumbent to defend their business, but at second glance it makes you say "yeah…we’ve had open phones for a while now. What just changed? Is it even material?"

Google’s campaign to perform competitive jujitsu using the malevolently humming light saber of openness is nice and all, but it’s a fact that I can write an application for my Windows Mobile phone today without having to pay anyone any money or ask anyone permission. (I don’t think the same is possible for my wife’s RAZR.)

Update: Looks like Om Malik shares my skepticism; he’s asked some even more incisive questions.

Google and Friends to Gang Up on Facebook

Link: Google and Friends to Gang Up on Facebook

“On Thursday, an alliance of companies led by Google plans to begin introducing a common set of standards to allow software developers to write programs for Google’s social network, Orkut, as well as others, including LinkedIn, hi5, Friendster and Ning, according to people briefed on the plans. Those people asked not to be named because they agreed to keep the alliance’s plans confidential.”

We’ll see what this looks like when it emerges, but whaddya wanna bet that the “standard” they come up with walks and talks like Facebook’s API yet is every so slightly different (and incompatible) with Facebook’s API?

And how is LinkedIn supposed to factor in here, I wonder, with their famous opposition to the notion of an open platform?

I’m still willing to accept that this initiative is getting lost in the NY Times’ muddled inability to do a decent and technically accurate story on Silicon Valley technology, but it really sounds Google is trying hard to turn “openness” and “interoperability” into the new “embrace, extend, extinguish” here. Which, if successful, would be quite a feat.

Update: A second-day story on this quoted Joe Krause on behalf of Google. From this one could deduce that Google’s entry into the “open but not Facebook” cabal will be the relaunched JotSpot, whenever they get around to re-launching it.

Update: Marc Andressen has more about this on his blog. I wish he’d posted this yesterday instead of letting everybody get half of the story via TechCrunch. Marc’s post clears things up a bit but I’m still interested in seeing what the bits look like. It seems like this is more an attack on Facebook’s proprietary markup language than anything else. Memo to interoperable social network cabal: there is no such thing as a platform that does not use some kind of proprietary semantics to map out its feature set. You’ll find yourself doing this as well if you haven’t done it already.

Side note to web marketers, PR mavens and evangelists: if you want to ensure that there is an elevated level of confusion associated with your launch, one sure way to accomplish that is to provide an exclusive leak to TechCrunch prior to your public launch. I know it’s virtually impossible to get on TechCrunch unless you give them a scoop, but there’s a cost associated with making those guys your media leak of choice. To put it another way, no product launch has ever failed because the product didn’t brief TechCrunch about it a few days ahead of time.

Update: Michael Arrington’s headline on this today says “checkmate!” which is of course nonsense since the game isn’t even half over, OpenSocial hasn’t even produced anything yet and Facebook could of course join at any time if they wanted. His commenters mostly seem to agree.

Saul Hansell of the NY Times has some less hysterical thoughts on this; he points out that “LinkedIn has also said it may ask for a revenue share from those who
create applications for its network. And haggling over money, no doubt,
will slow down the deployment of many social applications.” No kidding. This is my main concern about the path that LinkedIn is going down. Having to ask permission to build an app and then provide a revenue share isn’t a platform; it’s the definition of a walled garden. AOL was successful at this for a while in the 1990s because they were able to bring a mass audience when nobody else could, but these days, that dog won’t hunt, monsieur.

Songbird is for Developers

Online music aficionados may be familiar with Songbird, a promising music player that sports extensibility, skinnability and all-around open-source goodness. Built on the Firefox code base, the player is in development now, but it’s open to hackery by third-party developers — you can create extensions (just like Firefox extensions), user interface skins and more.

Songbird launched their developer site this morning. My consultancy, Platform Associates, participated in the launch, providing content strategy and content development, but the majority of the work was done by Songbird’s own terrific team. Great job, guys! This will really help developers discover the product and help to make it better.

Death To Outdated Developer Content

In a world in which many developers (myself included) use web search as their first avenue of inquiry when they run into a technical problem, it’s important for platform providers to have technical content that is thorough, well-organized, and discoverable from web search engines. (This means that you should apply the principles of search engine optimization to your entire site, not just the marketing bits.)

Way too many technology products expect third party developers to flock to their platforms on the strength of the product alone, without providing any documentation to help them get started. Documentation isn’t an amenity, it’s a requirement.

If your documentation isn’t easily searchable, then 10-70% of current and prospective developers aren’t going to be able to find your documentation when they need it.

Keeping your developer content up to date as your platform evolves is another big challenge. Microsoft does a terrific job of keeping its voluminous body of developer content current while deprecating and removing old content. Not so, unfortunately, with the large number of third party community sites that cover Microsoft technology. In this situation, the third parties’ objectives aren’t in alignment with their users, since (presumably) taking down outdated content decreases the third party sites’ pageviews and clickthroughs.

This came up today because I’m investigating how ASP.NET developers can localize their sites into different international languages. As it happens, the rules pertaining to localization totally changed from ASP.NET 1.1 to ASP.NET 2.0. (Things got much easier in 2.0.) Since I didn’t know much about localization in the 1.x era (Chris Kinsman and I didn’t cover it in our ASP.NET 1.0 book), I started with a web search and immediately ran into a ton of outdated content on .NET localization which wasted several hours and made me semi-cranky.

After many wrong turns, I wound up at the place where most .NET developers begin: the QuickStart Tutorials. The tutorial for localization in ASP.NET 2.0 is terrific and it got me what I needed in a hurry. (All of Microsoft’s .NET QuickStart tutorials are terrific, really — if I had to point out a single thing that helped .NET get adoption since it was introduced in 1999, the QuickStart Tutorials are probably it.)

The point is that even the biggest-brained developers can benefit from simple tutorials to get started on your stuff. I wish Mono had tutorials (covering configuration, etc.) that were as good as Microsoft’s. I wish PHP did, too. Also Flex. I didn’t need a quickstart tutorial to figure out MySQL but I suspect there are a lot of developers out there who could benefit from one.

Actually, these platforms may very well have great tutorials, but I never run across them, which suggests to me that they’re missing something in the search engine optimization department.

I was talking with a prospective consulting client last week and we were trying to figure out where my services could fit in. I told them that while most of the consulting I do today pertains to product strategy, I’m not above doing super tactical stuff like technical documentation for them (as long as they realize that, as technical writers go, I’m on the pricey side). I offered to do this because good tech docs people are really hard to find and they tend to be unappreciated. I’m actually surprised that there aren’t consultancies specifically dedicated to doing technical documentation — maybe that’s because companies aren’t willing to pay for documentation the way they pay for software engineers.