Some Twitter developers are worried, and even started a Twitter hashtag to discuss it, #unionoftwitterapps. But software developers who build on top of platforms have always experienced the same give and take, other developers say.

“There’s some misunderstanding around platforms,” Mr. Williams, also a Twitter founder, said in a recent interview before the storm blew through the blogosphere. “I’ve been trying to figure out how to talk to developers about this.”

Free advice for platform providers: Figure out how to talk to developers before you make your platform available.

via Evan Williams’s Message to Twitter Developers – Bits Blog – NYTimes.com.

Figure Out How To Talk To Developers is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

I just noticed that the upcoming San Francisco Open311 initiative is planning to coordinate its efforts with a similar initiative underway in Washington, D.C. with the ultimate goal of making their systems interoperable. This is outstanding news; it means that if a developer builds an application that targets a data set emitted by one government agency there’s a decent chance that application will work against any similar agency’s data.

After machine readability, interoperability is the final frontier for open data. It’s not enough to post meeting minutes online as PDFs (the format where data goes to die), and soon it won’t even be sufficient to post it in a machine-readable format; data needs to be structured consistently. If every municipality invents its own format, this movement will be stillborn.

Link: San Francisco and D.C. Set to Launch Open311 APIs

Cities Starting to Collaborate on Open Data Initiatives is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

Since the new partner service (PriceGrabber) apparently doesn’t have a public API, that essentially kills this API. Killing an API is a very big deal, not just because it kills applications — it kills your credibility as a platform provider. I’d be very reticent about adopting any technology integration provided by Yahoo until things settle down over there. That said, there would have been a potentially interesting opportunity for PriceGrabber to provide a compatible API and make the developer switchover fairly seamless. It’s anyone’s guess as to why they elected to not do that.

Ben Metcalfe has some “cautionary” words which I think describes Yahoo’s lack of developer/platform strategy pretty well. The company’s developer releases over the past few years have mostly fallen flat for a variety of reasons (lack of business value for third parties being foremost, I would say, although there’s also a very unfortunate lack of organizational focus and unclear articulation of product strategy and tactics at work here as well). It was not clear to me that enough of Yahoo’s execs valued third-party developers in 2006 when I left the company, but it’s quite clear that they value third-party developers and open integration even less today.

Yahoo Pulls Plug on Shopping API is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

We haven’t actually released new APIs; what we have done is that we announced a set of APIs on November 3rd, which was our adaptive suite. Adaptive suite APIs include adaptive payments and adaptive accounts. Then we also announced our authentications and permissions API. What we had done at Innovate was to make those APIs exclusive — adaptive account, authentications and permissions, exclusive to the attendees of the conference. We did a full-on release for those APIs on November 3rd when we announced the platform. But we’ve had an overwhelming response from the community where people where saying, “You’re limiting us from actually using these APIs. Is there any ability for us to get these early on rather than to wait until 2010?” Based on the feedback, based on what people were looking for, we decided to open it up to everyone now, instead of sometime in 2010.

This quote is from Naveed Anwar of PayPal. It’s supposed to shed some light on the new PalPal platform. But I feel like I’ve been following the reboot of the PayPal platform for a month and a half now, and I’m still not sure I understand just how it’s supposed to help me. Apparently there is some conference that I was supposed to have attended? And if there are no new APIs, what has changed? Adaptive suite? What is that?

It’s not really possible to get the information you’d want from their web site, which at the moment is dominated by information about a new developer contest. (Developer contests are problematic on their own, as I’ve written about here previously.)

I’m really concerned that PayPal, like Yahoo and others, is going to miss a huge opportunity here by failing to articulate its vision in a straightforward way. (On second thought, screw the vision. Maybe just focus on saying what your products and services do on your web page first.)

How Not To Describe Your Platform is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

Having produced content to support a variety of technology platforms for more than a decade, I’ve come up with a few very general strategies for how to approach this.

The first strategy is Identify and Develop Reference and Narrative Documentation. Reference documentation is the bare-metal documentation that anyone would need to use your platform. This is the absolute minimum you can do in terms of documentation and content — without it, nobody will be able to figure out what you’re doing. Narrative documentation is far less dense than reference documentation; a good example of the difference is the Java tutorial for exceptions versus the reference documentation for the Exception class. Typically, reference documentation is delivered by your engineering team; narrative documentation is provided by technical documentation specialists.

The second strategy is Build Content Out To the Last Mile. It’s not enough to run an automated documentation generator on your source code and upload it to a web server, or even to set up a wiki and declare victory. You have to create technical content that is going to speak to software developers where they live, and generally that means writing to some kind of programming language. The languages you target will differ depending on several factors, including the programmability model of your platform, the amount of resources you have to devote to content, and the expected number of developers using each language you want to address.

Some examples: Let’s say you’re Palm and you want lots of developers to adopt WebOS. You have something of a head start here because you’re leveraging a single, commonly-used language (Javascript) and other web-centric technologies that a lot of web developers use. But there’s still a Last Mile for you: you’ve got an SDK, a Javascript framework, and a bunch of paradigms that are unique to mobile development.

On the other hand, if you’re a web services platform or some sort of back-end product, your Last Mile strategy is a little more complicated because you’re not tied to any particular programming language. That means that your Last Mile is the all programming languages used by your current and prospective developers, multiplied by the different pieces of narrative content that addresses each of those languages. I like to arrange this in a grid, like this:

Making this into a grid turns it into a handy two-dimensional task list. It also informs where you devote resources (and potentially how you hire people; when we realized that PHP was important at eBay in 2004, and we had exactly zero PHP content, I hired a PHP guy pronto).

There’s a lot here, but the good news is, you only have to fill in each cell in the grid once. To manage resources, you are also likely to draw a horizontal line somewhere on the grid; languages below that line don’t get direct support from you (although you can graciously accept support from the community for edge-case languages that you can’t or don’t want to support directly). But the number of languages that you choose to support should exceed one (this was a serious problem in Facebook’s platform content until very recently).

Also, as you add major new features to your platform, you will of course add new columns to the content grid so that you cover your new features in all the languages that matter.

All that said, it’s also possible (even common) for platform technology organizations to over-plan their content strategy. This isn’t quite the same as what software architects refer to as “analysis paralysis,” but it feels the same. When you hear things like “we want to make sure we specify exactly what content we’re planning on publishing before we create a system to manage it” or “we don’t want to publish anything until every piece of content is ready,” these are signs of an over-planned content strategy. Best in this situation to develop the content you have, get it out there as soon as possible any way you can, and iterate on it frequently in collaboration with the developers who are using your platform.

This process supports a few tenets of the Platform Manifesto: actively managing platforms, nurturing communities of users, and providing self-service access.

Technology Platform Content Strategies is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

If true, this could be huge. It looks like the premise is that third-party developers will be able to get access to Facebook data (including photos) through new APIs.

This could make Facebook much less of a walled garden and give them a more compelling competitive response to services like Twitter.

Facebook To Let Others Play In Its Stream is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

This violates our first rule of platforms (“A ‘proprietary platform’ isn’t a platform”). Put another way, if you have to ask permission to develop a piece of software on a platform, that platform isn’t open — it isn’t even a platform (it’s a walled garden or a collection of integration points). If you attempt to build a business on such a product, you run the risk that the company that owns the product can destroy your business at any time, for essentially any reason. You are, in essence, a sharecropper.

The amount of revenue that Apple will lose from a third-party podcasting application is zero. The number of developers who will think twice about developing for the iPhone because of these capricious policies is almost certainly more significant.

Update: It’ll be interesting to see if Apple relaxes their rules in response to today’s release of the Android Market, the open application store for the new Android phone.

The iPhone is Not a Platform is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

In the consultancy I have to talk startups’ attorneys off the ledge quite a bit. I have two talks that I find myself giving over and over with lawyers: the Open Sourcing This Tool Does Not Invalidate Our Entire Business talk, and the You Don’t Get To Invent Your Own Open Source License talk.

So there can be a pretty big divide between what lawyers want and what product managers want. Their interests are slightly out of alignment (product managers want to deliver feature functionality to customers; lawyers want to insulate the business from legal risk), but that’s okay. But it does mean that these two roles need to figure out ways to communicate and negotiate to move the business forward.

Not too many people get excited at the prospect of a meeting with a lawyer, and lawyer-wrangling is not the kind of activity that product managers get much credit for. There were several developer products my team released at Yahoo! that would not have seen the light of day if my team hadn’t devoted a bunch of time to convincing the attorneys that it was in the company’s advantage to releasing them. We certainly didn’t devote the majority of the time that went into creating these products, but it’s a fact that if it weren’t for the time we put in with the lawyers, the products wouldn’t exist today as products (they’d be a set of firewalled APIs or internal tools).

So I was thinking about this dynamic this week following the release of the Google Chrome browser. The product used the standard Google licensing agreement, which gives Google a non-exclusive license to anything you submit to a Google service. Because they used the same license on the browser, people who didn’t read or understand the legalese came away with the impression that Google owns everything you do using the browser. And “non-exclusive” is key here (it means they can use your data — in a search index, for example — but they don’t “own” it). Still, it freaked some people out and for good reason — the one-size-fits-all nature of a license agreement that’s appropriate for a web site isn’t necessarily going to fit well for a browser product.

Google has since said that they’re going to look into the licensing and retroactively remove the clause from the license agreement, but in a lot of ways the damage is already done — the license kerfluffle culled some momentum from their launch and made them appear less than thoughtful. Getting this stuff right is the kind of thing that a good product manager does.

Product Managers, Lawyers, and Google Chrome is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

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.

Death to Developer Contests is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.

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.

Mono’s “Usability Disaster” and Platform Discovery Optimization is a post by Jeffrey McManus of Platform Associates. Follow Jeffrey on Twitter.