Finally, Tweetbot for iPad came out. I've only been asking them for, like, EIGHT MONTHS! Jeez.

Apple fiiiinally released iTunes Match after a whole month, and it didn't even work right!

Listen to how this sounds. How do we, the tech bloggers, get away with headlines like this? Where do users get off complaining impatiently about updates to a service that costs them $2.99? Or a free service? Let's have a reality check. Remember how awesome technology is?

Let's Walk From San Francisco to Los Angeles

Sometimes, it takes longer to build amazing software than developers planned back at the beginning, when they were all psyched to get started. A great Quora thread about this popped up last week: Why are software development task estimations regularly off by a factor of 2-3?

Michael Wolfe's answer lays it out. Developing software is like planning a hiking trip down the coastline. When you're zoomed out, looking at the big map, the line is pretty straight. But as you actually start walking, you realize that the line on the big map glosses over the details.

The actual coastline twists and turns. There are cliffs and boulders and sand. "Angry sea lions!" It's not as simple as walking a straight line for the distance calculated by Google Maps. It might take 10 times longer to go one mile today than it did to go five miles yesterday.

So that's the part of the problem we can't control. Software projects take longer than expected. But the customers - and the bloggers - have to do more than just cut the devs some slack.

An App Costs 1 Cup of Coffee

We have to appreciate a few things. First of all, if you can afford a computer, if you can afford a monthly Internet bill, you can afford an app that costs $3. Let's assume we're talking about Apple stuff here. If you paid $3, the developer made $2.10 (and Apple took 90¢).

Just think about how many times a developer has to make $2.10 in order to make a living. That is your personal share of the app you bought. If it takes the developer a month longer than you wanted for a big update full of new features, just keep that in mind before you go ranting off to the Internet and leaving ★☆☆☆☆ reviews.

If the app is free, you should be saying "thank you."

Time & Perspective

The other part of this problem is our perspective on time. This is the one that affects the bloggers. We have our noses in this stuff every day, so the cycle of software releases tends to feel longer than it really is. But it affects lay users as well. We've gotten so used to things changing online all the time that we've started to think one month is a long time for a technological innovation.

That's craziness. It used to take a month to send a message to someone. Let's dial back the whininess and appreciate the amazing speed and plummeting costs of technological change. You can write your best-selling novel on an app that costs as much as a beer. I'm reminding all of us, especially myself, to try to stop saying "finally" and start saying "thank you."

Lead photo courtesy of Shutterstock

We asked and culled your responses from Facebook, Google+, Twitter, the original post and we used Storify to present it all back to you. If you have additional responses, please leave them in the comments.

I don't know about you, but when I hear the word "Lollapalooza," I think about beer, grunge rock and application programming interfaces. Wait, what?

Okay, so maybe an API isn't exactly what comes to mind, but this year, the rock festival that once helped propel bands like the Red Hot Chili Peppers and Pearl Jam is looking to launch something else entirely: an open API chock-full of real-time scheduling data, stage geolocation and more.

Lollapalooza is offering over $5,000 worth of prizes and tons of promotional exposure for the best mobile, web and desktop apps created using their API. Developers can access data on artists, events, stages/venues and updates for Lollapalooza 2011. Prizes will be awarded for apps that help fans get the most from their Lollapalooza experience before, during and after the Festival. Winners will be promoted on the official Lollapalooza website and to fans via email, Facebook, Twitter, and the jumbotron screens at the Festival.

The HackLolla website has the full list of rules and deadlines.

If music and hacking are your thing (and let's face it - you're here, so they are) then you might also want to check out this weekend's San Francisco Music Hackday, which is being sponsored by Lollapalooza. The company will be making a more in-depth announcement on HackLolla. Immediately following, San Francisco will be home of the SF Music Tech Summit.

In all, it's a good time to be a music-loving hacker.

Last month at SXSW, Infochimps, the self-described "Amazon of data," unveiled thousands of new API calls. The API calls, or plug-and-play bits of code that developers can insert into their applications, were released in hopes of soothing the headaches inherent in making data-dependent applications.

This weekend, a few developers took three headache-free days to make three awesome Twitter apps built on the Infochimps API calls.

Check 'em out.

If you search on Twitter, the results you get come from what a person says in their tweets. It doesn't search their bio. Plum.ly allows users to keyword search across anyone's Twitter bio and returns results according to TrstRnk, the Infochimps' Twitter-influence score. It lets users search not only the bio, but also the name and location. For example, if, like me, you wonder who else made the reverse migration, you can look for "Austinite in San Francisco." It even allows users to quickly look at these results and see who these people are communication with on Twitter and look at the conversations they're having.

Steve Odom put it together using the Strong Links, TrstRank, Conversations, and Qwerly API calls.

TweetDegree - follow the right people

Say you meet someone involved with the Android developer community and you want to meet more people like them. How would you go about that? One way would probably be to look at the people they talk to and communicate with most, right? TweetDegree does just that. It helps you to quickly find the people they follow and Interact with on Twitter. Just enter a name, and it shows the various levels of interaction from there.

It uses the Infochimps Strong Links and TrstRank API calls and was built by Taecho group.

TweepleFight - measure Twitter topics in microBeibers

Everyone loves a good fight, right? Infochimps' own CTO, Flip Kromer, built this Twitter-based battle that allows users to compare the relative frequencies of words or phrases using Infochimps' Twitter People Search API. Far more interesting, though, is how it makes these measurements - in "microBeibers." What in the world is a microBeiber?

*µBb (microBiebers) -- Each microBieber corresponds to one-millionth the popularity of Justin Bieber in user profiles. For example, about 10,000 users mention "bowling"; as a fraction of the 200,000 who mention "Bieber", that's 5.3%, or 53,000 µBb.

I guess we can't take down the king himself.

For more about the Infochimps' API calls, read Sarah Perez's full write-up from SXSW.

While Twitter's "days of imminent technical meltdown" may be in the past, the company has run into a host of other troubles in recent months. As a part of its efforts to monetize and stabilize its once shaky servers, the company has sent signal after signal that developers should watch where they stand, lest they be squashed in future developments. The effect has been one of creating a great deal of fear, uncertainty and doubt amongst those - the developers, founders and CEOs - who have elevated Twitter to the height it enjoys today.

This week, however, Twitter co-founder Jack Dorsey announced his return and these self-same members of the Twitter ecosystem have renewed hope that they and Twitter could work together again.

"Today I'm thrilled to et back to work at @Twitter," wrote Dorsey, "leading product as Executive Chairman. And yes: leading @Square forevermore as CEO. #200%"

The announcement has proven to be good news for many in the ecosystem and we asked around to see what the founders, developers and CEOs who've found themselves in the middle of it all lately had to say.

TweetDeck CEO Iain Dodsworth

"I think having the father, the architect of Twitter (the service) returning should galvanize the team around his product vision and direction. Can't see that being a bad thing. Unsurprisingly, I'd ask if this vision is predicated on the one size (UI) fits all - although I'd ask that of a lot of services, especially Facebook."

TwapperKeeper Founder John O'Brien

"Jack's return will be a huge step in the right direction. I believe we will see more innovation in the Twitter product / platform - which will be good for both users and developers. However, I don't necessarily think that we will go back to the wild wild west of the early days. I think control (via ToS, etc) will continue to be maintained as the platform matures and strives for profitability.  But a step in the right direction no doubt..."

Keepstream Co-Founder Jim England

"As a founder of a startup that integrates with Twitter, the announcement of Jack Dorsey returning as executive chairman is a positive sign that the company is looking to reduce the tensions between Twitter and the developer ecosystem. As one of the original visionaries for Twitter, Jack is uniquely positioned to re-align the company and mend fences from the ubermedia and #dickbar events. [...] Structurally, Jack's return will not directly affect developer relations. The new rules that @rsarver posted aren't going to change. Emotionally, however, bringing back an original co-founder seems like Twitter is moving in the right direction to 'fix' things."

Favstar.fm Founder Tim Haines

"Personally it gives me hope that some of the awesome from years past will be returning to Twitter. Most of the innovation over the last year or so feels monetization orientated - not for the users benefit. While that's got to continue to grow Twitter's profits, I hope that we see some more interesting innovation occurring again. They've innovated in their clients - but not so much in the base utility that's available for apps to build on top of.

I think a common feeling amongst the developers I've spoken to is that Twitter's sent a pretty clear message with their last API announcement.   Basically that they're not interested in external developers playing much of a role in the ecosystem anymore.  I don't think Jack's involvement will change that.

As a user, I have hopes that he'll be bringing more innovation to the core product (probably to Favstar's deteriment eventually) and we'll be seeing Twitter becoming a more useful tool for finding out about topics you're interested in, rather than just following people you're interested in."

Seesmic Founder Loic Le Meur

"Jack is a visionary and he invented Twitter. It can only be good news that he's coming back somehow to drive product. I am really glad to hear that and I could not believe it at first. It's also great news for the developers as Jack really values an ecosystem around his product. I think Twitter has grown up though and won't let others compete with its users eyeballs and advertising dollars, that's why I'm happy I have positioned Seesmic to help brands grow on Twitter, we're not competing in any way."

Hacker Advocate Abraham Williams

"Square has amazing polish and refinement. If that eye for detail is turned to @twitterapi it could push it to the next level."

What do you think? Will Jack's return be good for users and developers alike? Or has Twitter set in motion the eventual demise of its developer ecosystem?

This morning TwapperKeeper, the Twitter-based service that allowed users to create and export archives of Tweets around certain words or hashtags, announced that it would be shutting down a number of key features of the service to remain in compliance with Twitter's Terms of Service.

According to the company's blog post, the archiving and API features will be shut down by March 20. While TwapperKeeper may be just one service among many to be forced into compliance, is its fate indicative of a larger movement in the Twitter ecosystem?

The particular clause in the Twitter TOS (1.4.A) says that you will not "sell, rent, lease, sublicense, redistribute, or syndicate the Twitter API or Twitter Content to any third party for such party to develop additional products or services without prior written approval from Twitter."

According to O'Brien, this move by Twitter could signal that any service that engages in providing structured data not solely for personal use will be affected.

"What I'm seeing is, anybody who is 'syndicating' content, ie allowing it to be downloaded and exported in any structured way, is running afoul of the terms of service," said O'Brien. "If it's in HTML, it's fine. The minute it became structured it became a problem."

The End of An Era?

Hacker Advocate, Web API geek, and @answerly developer Abraham Williams lamented the news, tweeting "RIP Golden age of Twitter -Twapper Keeper removes features/API because of Twitter TOS."

Has something indeed changed? Has the "golden age of Twitter" come to an end?

Twitter has been cracking down on a number third-party services and features over recent weeks, with the official shut-down of the API whitelist earlier this month and last week's crackdown on UberMedia. In its announcement that it had shutdown Twidroyd and UberTwitter, Twitter said that every day it "suspend[s] hundreds of applications that are in violation of our policies. Generally, these apps are used by a small number of users." While TwapperKeeper may be just one of hundreds, it has been around for nearly two years with a number of users relying on its API and export features.

So how might this be the end of an era? Williams said that things have changed for anyone considering a startup around Twitter's platform.

"Before Chirp last year and before Twitter bought Tweetie, few thought twice about building a company in the Twitter ecosystem." said Williams, "With recent events I would more then think twice (probably think three/four times) before building a Twitter based company."

The Question Is, Why Now?

TwapperKeeper got its start in June 2009 and has been offering API access for almost that entire time. O'Brien says that he even submitted whitelist requests early on explaining exactly the nature of his service.

We asked Twitter about the situation and were told that it is a matter of its TOS and Twitter stability.

"We ask all developers in the Twitter ecosystem to abide by a simple set of rules that are in the interests of our users, as well as the health and vitality of the platform as a whole," said a Twitter spokesperson. "We often take actions to enforce these rules; in fact, on an average day we turn off more than one hundred services that violate our API rules of the road. This keeps the ecosystem fair for everyone."

On the point of Twitter's "health and vitality", Williams pointed out that if nobody can create their own API, then everyone has to use Twitter's, which could put a much larger strain on Twitter's API.

In all, Twitter keeps pointing to this "simple set of rules," but why hasn't the company enforced the rules until now? Has TwapperKeeper simply flown under the radar for the past year and a half or has something fundamental changed?

Is It So "Simple"?

Favstar.fm founder Tim Haines explained that API access to Favstar is something that developers have been asking for, but Twitter has turned him down. Enforcement, he says, has been less than uniform.

"I've casually asked Twitter if it would be okay to offer one in the past, and they've said no," said Haines. "It's a rule that's not very well enforced at the moment, as a lot of services, high profile ones included, offer an API that makes Twitter information available outside the terms they've agreed with Twitter."

While Haines plans on continuing to petition Twitter for this sort of functionality, there is another service that we were pointed to by several sources that seems to stand in direct contrast of Twitter's stated point.

Twitoaster, a service that "threads and archives your conversations in real time", offers an API and has publicly done so for some time. The service was created by Arnaud Meunier, who is now a Twitter employee. The key part of the Twitter TOS that must apply here is the "without prior written approval from Twitter," though inquiries on whether Twitoaster had this approval went unanswered by both Meunier and Twitter.

Whither Twitter As A Platform?

In a guest post here on ReadWriteWeb yesterday, TextCapital founder Jeff Pester argued that Twitter is a utility and needs to "get off the fence and start acting like one."

The blogosphere is preoccupied with the notion that this is proof that Twitter is at war with the developer ecosystem and that it's somehow manipulating the playing field to favor its own homegrown apps.

But that discussion misses the larger point: Companies like UberMedia are attempting to profit directly at the presentation and consumption end of the stream infrastructure that Twitter has bought and paid for. In my opinion, UberMedia has the right to monetize "consumption environments" (its apps) that add value to end users. At the same time, Twitter deserves to be compensated for the utility it's providing to UberMedia.

The only issue here should be: Who gets paid and how much?

The big problem now, of course, is that developers have been working in a certain system for years and some feel that the rug is suddenly being pulled from beneath their feet. At the same time, developers have pointed out that a more stable service with clear definitions on its rules can benefit everyone. Haines explained that, by shutting down services that don't meet the TOS, Twitter can clarify its position to all - a position that has been stated rather simply, but enforced less so.

"It'll be good if Twitter is currently taking some time to clean up rogue services," said Haines ,"and make it clear what they allow and what they don't allow."

The more general and obvious trend in all of this is Twitter's move toward monetization. When Twitter killed the API whitelist, the primary suggestion for services that required more historical Twitter data was to pay Gnip, the only authorized reseller of Twitter data. When UberTwitter and Twidroyd were suspended, Twitter just happened (perhaps it was a terrible, coincidental PR failure) to be promoting its own clients with promoted trends. O'Brien couldn't help but reach a similar conclusion.

"I'm wondering if tomorrow they're going to be saying there's an archive open," said O'Brien. "I'm just speculating."

Last night, Twitter made official what many members of the developer community had long suspected - there would be no more whitelisting for data-hungry apps. For some developers, this either means that they have to come up with creative work-arounds or, for others, that their projects are dead in the water.

So why did Twitter kill the exception to the rule and what does it mean for the future of Twitter apps and the developers who create them?

First, a quick primer on whitelisting. Whenever you use a third-party service that integrates with Twitter, it likely uses the API (application programming interface) to get data - to get your @replies, direct messages, tweets and so on. To make sure that these apps don't overrun the servers, however, Twitter imposes a rate limit, which means they can only make so many requests per hour. For more data intensive services - think Klout, Hootsuite or Twitalyzer, for example - these limits are far too low for them to operate. That's where the whitelist comes in. The "whitelist" is simply a list of services that are allowed to make a much higher number of requests per hour. By much higher, we mean 20,000 compared to 350.

So, What Has Changed?

Yesterday, Twitter platform lead Ryan Sarver announced on the Twitter Development Talk group that "Twitter will no longer grant whitelisting requests." Sarver describes the feature as a holdout of a time before Twitter offered other methods to access its data.

Twitter whitelisting was originally created as a way to allow developers to request large amounts of data through the REST API. It provided developers with an increase from 150 to 20,000 requests per hour, at a time when the API had few bulk request options and the Streaming API was not yet available.

Since then, we've added new, more efficient tools for developers, including lookups, ID lists, authentication and the Streaming API. Instead of whitelisting, developers can use these tools to create applications and integrate with the Twitter platform.

The real change, however, comes a bit further down into Sarver's announcement when he notes that "there are going to be some things that developers want to do that just aren't supported by the platform." Instead of granting whitelisting to make advanced research and analytics possible, writes Sarver, developers will need to contact Gnip, a reseller of Twitter data.

Why Get Rid of Whitelisting?

According to Abraham Williams, a "Hacker Advocate" and developer at Q&A startup Answerly, Twitter is getting rid of whitelisting to push developers onto its streaming APIs. That, and keeping Twitter up an running, of course.

"They're essentially saying if you can't get your data in real time or in less than 350 requests in an hour, find something else to do," said Williams. "Every API has some kind of rate limit and a lot of them don't have whitelisting."

Twitalyzer founder Eric Peterson agreed that it was likely a matter of necessity.

"Is this a reasonable thing for Twitter to do? It is. This is about their growth and stability as a platform. Developers are secondary," said Peterson. "It's probably just a natural part of their growth. They must have hit the wall from a technology perspective."

What Does This Mean for the Twitter Ecosystem?

When Twitter started out in 2006, it was a simple, SMS-based service that allowed a small group of users to communicate with each other and put that content on the Web. A short six months after the service was born, the Twitter API was introduced. Ever since, developers have been creating apps around the microblogging system, using the data to analyze individuals social influence online, communications habits, and even worldwide trends. Those ideas that needed access to more data were able to requisition the company for whitelisted access. Now, whitelisted companies will be grandfathered in, but the doors are closed to everyone else.

So who will this move affect, first and foremost? According to Twitalyzer founder Eric Peterson, the most affected will be "everyone who for the last three months has been building stuff on the API" and waiting to hear back on their whitelist application.

"You can't really do a ton without that whitelist," said Peterson. "We would have run into rate limits in the first couple months and probably have said forget it."

One developer notes in response to the announcement that he needs around 800 requests per hour and that "This and a few other ideas I had just died."

Williams explained that the changes affect some developers (and ideas) more than others. He said that sites could use the streaming API and collect data moving forward, but gathering historical tweets will be a problem.

"The people who are up in arms about it are the people who need access to historical data," said Williams. "If I wanted to build an app that would search the tweets of people you follow and you followed more than 20 people, I wouldn't be able to pull your entire Tweet history."

That Leaves Us With...What's Next?

Of course, what's a limit without finding a clever way around it? The party line from Twitter on this one is that, if a developer needs more data than allowed, they'll need to pony up the bucks to Twitter data-reseller Gnip. As Ed Borasky, a data scientist who does work in text mining, journalism and social media, notes on the Google Group discussion, this squeezes out the little guy.

[Gnip is] a non-starter for small consultants, startups or non-profits. We simply will find problems to solve that don't require subscriptions to a high-volume and high-priced source of *raw*, *unstructured* data. There are plenty of large corporations who can sell "business intelligence" to other large corporations, but that's not a game that a small business can play. I am not a qualified prospect for Gnip's service and you shouldn't be pitching it to me. ;-)

From here, two are two distinct possibilities. First, developers will find a way over the wall and create alternative methods to get data, through nets of fake accounts or other methods. The second possibility - one requested in the conversation by Twitter API consultant and trainer Adam Green - is that an open market open up for Twitter data.

Now the next step in opening up this marketplace is to create multiple resellers of Twitter API data, and let them compete on price. Giving Gnip a monopoly over this market makes no sense. Twitter's biggest problem is the huge volume of requests. By blocking whitelisting you are forcing some developers to cheat by creating multiple accounts and distributing their requests across them. That can never be stopped. What you have to do is make it inefficient, by letting multiple resellers complete and drive the price of Twitter data down. Then the strongest reseller will take the load off of you and offer enough value added that developers will be willing to pay for data. That will never happen when only one reseller sets the price.

Twitter has benefited over the years by all of the additional value added by its developer community and hopefully the end of the whitelist won't aversely affect this same community. Green ends his note with a well-wishing to Twitter and we'll end with the same.

"You are riding a tiger. Good luck, and try to stay open and honest. This is a good step on that path," writes Green. "As long as you tell the truth, you will succeed."

The site offers a way for you to make your own app, ready for the Market, in just a few minutes. Once you sign up for a Feed.nu account and upload your feed info, you're able to download a .apk that you can, in turn, upload to the Android Market.

You can blog directly into the Feed.nu interface (it's simply a hosted WordPress blog), and edit your posts there, should you choose. As it's based on your RSS feed, the app will update as you update your blog.

It's still in beta, but it's a fully-functioning beta, so check it out.

It's 2010 - disruption is everywhere. The pace of technology is quicker and faster than ever before. News of iTablets for touch-screen magazines alerts us that we're living in a multi-channel, multi-platform, multi-device-kinda world. So how do we keep up with innovation while being mindful of resources and cost-savings?

Did you recently launch an API? Congratulations! You have just inherited a brand new customer base: developers. Treat your developers with the courtesy you would extend to any customer of your business. Hear their suggestions, incorporate their feedback and let them know you are listening. Ignore your new set of customers and their needs, and they'll be sure to return the favor.

Focusing on customers requires an exercise in understanding, segmenting and mapping to help you achieve broader corporate goals. Regardless of the stage of your API platform (planning, building, sustaining) this post will provide a useful look into how to plan for successful developers on your platform.

Define Success, Stay Focused

Value can't just be perceived, it has to be actual. The API platform cannot stand alone; rather it needs to be tightly integrated with business objectives in mind. A good top down approach for planning your API starts by defining what success is for the company. Supporting corporate markers for success will get you the executive buy-in you need to boost your API efforts. Mapping your success through goal setting and measurement processes keeps you cognizant of both short and long-term opportunities.

Next, align your platform strategy with your business strategy - identify company-wide goals to measure against. For example:

• double revenue for the company in five years
• increase user / consumer engagement by 12%
• reduce partner implementation costs by 30%
• increase the number of new Tier 1 partners by 10%
• increase the number of internal projects delivered by 20%

It's important that the API platform be accountable to the business strategy, by generating revenue and driving partnerships, within a sustainable platform growth model. How else will you know when you've been successful?

Developer Segmentation Strategy

You know the business goals and have analyzed the success markers. But now you need to evaluate the best approaches to achieve developer success within your API universe. Start with a classic business customer segmentation study to identify and prioritize your developer audiences. This will help you formulate a clear and effective value message to encourage more developers to consume your API.

To build your segmentation study, answer this series of strategic questions:

• Do you know who your developers are?
• Do you know what programming languages (PHP, Ruby, Python) and platforms (mobile, widget, browser) your developers are using?
• Do you know what influences or motivates your developer to build on your API? (Money, fame, fortune?)
• Do you know the proper channels to reach your developers? (Where do they live, work and play?)
• Do you know who amongst your developers are the most profitable partners?

Consider both qualitative and quantitative information to inform the decisions above. Once you've established developer segments, it becomes easier to tie opportunities back to the corporate business goals. And it's imperative to consider the available resources (time, workforce, finances) to create realistic platform goals.

Focus, focus, focus. Go after your priority segments first, given the reality of limited resources. This is an important exercise in platform planning that adds communications efficiency, and better overall potential revenue performance of your API platform.

Community Feedback

If you've already launched an API platform and have built up a small (or large) developer network, then be sure to garner feedback directly and indirectly from them. Surveys, polls, discussion boards, comments, tweets and social buzz tell you how the community feels about your API, brand and efforts. So pay close attention, and analyze the numbers too. Look into your developer portal dashboards (or reports) to get aggregate information on popular calls, methods, search terms, coding languages and other items that relate to the health and curiosity of your API network.

In addition to the segmentation questions mentioned above, consider your top developer targets, and the resources you need to provide to help them achieve success. It can be something as simple as language considerations.

Build in Success Metrics

As mentioned earlier, the API platform needs to play a role in the revenue growth of the company. Oftentimes, champions of API platforms struggle with proving the ROI of a program since it's a relatively new channel that has many avenues of use. The simplest and most powerful way to demonstrate the impact is to assess what can be measured, such as:

• revenue attributable to API
• CTR to pages with ad revenue via API
• affiliate CTR on content using API
• number of user of mobile apps built using API

And since a robust, active and engaged API network leads to more creative developments, take note of metrics that substantiate a healthy community, such as:

• number of developers
• number of live applications
• downloads of your SDKs and toolkits

This combination of strategic thought-starters for platform planning and developer segmentation is hopefully a guide for you to get the most out of your API platform. So remember, treat your developers like customers. That's the best rule of thumb when it comes to creating a robust developer community around your API program.

The holidays are underway and 'tis the season of flowing eggnog, overgenerous meals, and contemplation of both the year gone by and the year to come. Reflecting on 2009, it's obvious that there has been phenomenal growth in the business of APIs with recognized sites Best Buy, Netflix, Etsy, New York Times, CBS Interactive, PayPal, LinkedIn, and others keeping busy ramping up their API platforms to extend their businesses in new directions.

Here we present you with some thought-starters to help you with your 2010 developer community resolutions:

Give the gift of self-help documentation and support

Developers are smart. They are motivated to find the answers themselves. Establish your developer portal as the face for your API platform. Supply effective tools and the latest information about your API to give developers the answers that they are seeking. Always start with a value statement about your platform that answers the question: "Why would a developer want to build an application on this API?"

Consider both new and experienced developers and cater the value proposition so you can provide a reason for developers to build once... twice... and keep on building in order to grow your application portfolio. Your portal is the knowledge gateway to your community, whether they are new to your API offer or seasoned partners who want to get the latest status and release information -"Gee, I wonder when that bug fix will be taken care of so I can pick up development?"

Achieve this by applying a three-pronged approach to your developer portal and community tools:

• Developers go to your forums to search for answers, not to ask basic questions and wait days for the answers. Optimize search and prune your threads so that your discussion boards are a living knowledge base of accurate FAQs for your API platform.
• Always add a status dimension to your discussion boards. Badges, exposing number of posts, and user ratings are a simple way to provide your most knowledgeable and active community members with a stamp of expertise. Offer small incentives to your experienced posters who are willing to handle the newbie questions. Their help will free up your resources to focus on the more complex issues. So keep 'em happy.
• Include an open source dimension to your tools and documentation. Solicit input and suggestions, verify and proof the activity, publish or deny the post, and alert the contributors of the action. Open sourcing allows your API platform to support a greater breadth in coding languages and get updates updated more frequently.

Above all, if you launch an API platform, support it. By establishing the developer portal you are making a commitment that someone on your team will be there to respond to the developer community you are attempting to grow. Always continue to monitor and contribute to the discussions, and provide updates when and where relevant. Stay factual, be helpful, and don't hit send if you're feeling defensive. Moderators should be strong listeners because lessons from your community are the best feedback for successful growth.

Marketing is not a bad word

Don't be afraid of marketing. Bad marketing is a used car salesman trying to sell you something you don't need. Good marketing is information you need to make the best decision. Developers may say otherwise but they do respond to marketing that gives them useful information. Elevate and showcase the voices of developers who find information about your API useful. In many cases all you have to do is add a dimension of developer participation in marketing you are already doing.

• Feeds, Feeds, Feeds. Customizable, automated, real-time feeds. Blogs, Twitter, and RSS status alerts are simple to implement and create a stream of multi-channel activity that can be maintained with a lean team. Additionally, comments, re-tweets, and @replies are easy ways to track community interest, opinions, and trends.
• Be sure to list your API on ProgrammableWeb, a high-traffic directory and news source for the world of APIs. ProgrammableWeb is a prime resource for developers looking for new APIs.
• Look into adding a customer-centric Net Promoter Score (or NPS) metric to measure your program success. Knowing if your developer community would recommend your service to others adds an important satisfaction metric to gauge adoption and activation.
• Join the events bandwagon. No need to earmark non-existent funds for massive, impersonal developers conferences. Aim for an intimate, well-organized, and focused event to activate dormant developers into friendly evangelists.
• Recognize, celebrate, and reward good behavior. The more positive interactions you can create enables and grows ambassadors who do the job for you. Build a team of evangelists and allow developers to reap the rewards from their hard work.

Provide developers with compelling incentives and data sets to create value

Yes, of course, the business comes first. The decision of what data to expose with your API platform needs to support and align with your corporate and product strategy. But don't develop an API platform ecosystem built only to maximize value for your company positioning developers as the contributors. All stakeholders both contribute and extract value from a sustainable, healthy ecosystem. Don't forget to consider the value that your platform will provide to developers. Who are the customers of your platform and what are their needs? What monetization models would create the best incentives? What is the economic appeal of participation to developers? A popular API provides a compelling value proposition to the platform provider, the platform participants, and end users.

Know what to measure and why you're measuring it

A community for community's sake is a beautiful idea. But when backed by company resources, the community should exist to create value and opportunity around your API. Have the foresight to build in the right measurement tools to validate the effort. Consider your budget decision makers and track for success.

Start with straightforward quantitative numbers: live applications, developers that signed up for the program, API keys distributed; then calculate the activation rate percentage (number of live applications / total developers).

Identify any revenue figures attributable to your API. Depending on your API monetization strategy this could be through direct sales, revenue-share, advertising, affiliate programs, or another creative model.

Look into positive qualitative feedback and voices of members of your community - posts, tweets, comments - items that can showcase developer appreciation, interest, and evangelism. This feedback should be monitored year-round and shared with the platform team and executives on a regular basis. It's a human reminder of the intrinsic value the community work brings to the brand and business.

Would you host a holiday soiree and forget to prepare for your guests?

So there it is. Don't fall into the "build it and they will come" mentality. It's no fun to stand on the sidelines watching other communities have all the fun; you need to invite them to your developer party! Whether you are newly launching or extending your community efforts, try some of these approaches to propel your API platform strategy in the direction of growth in 2010 and beyond.

A complete list of APIs include:
1. Real-Time Stream API:This API gives developers real-time push capabilities. Developers can control data flow through a series of granular filters. In addition to Google, the company's first API partners include Groovy Corp and One Riot.
2. Status and Mood Commenting API: This tools allows developers to integrate MySpace mood and status updates to 3rd party sites. From there users can comment on the 3rd party site with real-time syncing to MySpace.
3. Open Search API: This allows 3rd party sites to include MySpace profiles in search results. While other services allow users to search for people by location, the unique aspect of this is that you can filter by words like "celebrity" and "musician".
4. Photo Upload API: This allows users to upload photos to MySpace from 3rd party sites.

In addition to the API tools, the company has improved it's post-to/share tools. Users can now post content from 3rd party sites and stream it directly to their MySpace activity stream with a link back to the original content.

To encourage creative use of the APIs, MySpace is also launching a developer's challenge. For info, developers can visit the MySpace developer's wiki.

For Users: Flexible Queries

One of the most interesting aspects of this library is that it gives users a lot of flexibility when they structure their queries. Ident Engine will happily accept full URLs like http://www.twitter.com/rww or just simply 'twitter.com rww' or the Webfinger email structure ('rww@twitter.com').

Not a Developer? Try these Demos

While Ident Engine is mainly aimed at developers, the team has made a number of cool demos available on its server. The Combined Profile Demo, for example, looks at a user's profiles on multiple services and then builds an aggregate profile for the user, based on commonalities it finds in these profiles. The Lifestream demo goes a step further and discovers a user's profiles on a variety of services and pulls in the latest updates. The project's homepage also features a number of additional demos.

Glenn Jones also recently released a Firefox plugin, Identify (our review), which builds on the same premises and allows users to quickly bring up the aggregate profile of any user while looking at one of their regular social network profiles.

Much like the original premise of Ning, Social Beans simplifies the creation of community websites.  However, since it is a portable format, a Social Beans site is not locked in to a single provider. In addition to the Grou.ps platform, the 0.1 version works with MediaWiki and WordPress. A Drupal plugin is also expected for October 2009. 

At this point, Social Beans is extremely experimental and while it's an interesting concept, the group's fate lies in 2 simple questions: Is it an easy enough template for non-technical users to adopt it? And perhaps more importantly, will developers build engines to run it? Let us know your thoughts in the comments below.

One interesting aspect of the directory is that Mozilla decided to eschew a standard, table-based layout for the directory in favor of an HTML 5 canvas based design that focuses on the products' logos. Because of this, the directory will only work on modern browsers like Safari, Chrome, Opera, and Firefox, but Internet Explorer users will be locked out.

As of now, only a small number of tools are in the directory, but, keeping in style with the purpose of the directory, Mozilla is using a Google Spreadsheet that allows developers to submit their applications.

We have to say, however, that the layout of the directory can be rather confusing and given that all a user sees is a product's logo, it is rather hard to figure out what a tool really does. As Mozilla adds more products, it will only get harder to use, though thankfully, Mozilla does also offer a plainer version of the directory.

More to Come

In the long run, Mozilla also plans to roll out comments, more social features, and ranking tools (maybe similar to what Launchly does).

As is typical for Mozilla Labs products, Mozilla is releasing this early and encouraging feedback from the community.

BeeJive, for example, is a great IM app - and so are eBuddy (iTunes link) and IM+ with Push (iTunes link), two other push-enabled IM apps that were released in the last few days. These apps are intuitive, connect to most popular IM networks, and work just as advertised. But when it comes to push notifications, there are just too many little things that are holding these apps back.

By default, BeeJive, for example, will log you out of your account after just 20 minutes. So once you have finished a chat session, you will just be offline again and no new messages will be pushed to your phone. You can push this timeout limit up to 24 hours, but this setting is buried at the bottom of BeeJive's long list of options. The eBuddy IM app doesn't even have this option and just automatically logs you out after 30 minutes.

There are probably good technical reasons for this, but this behavior just isn't what we expected when we first heard about push notifications.

News Updates are Nice, but What About Customization?

While the AP Mobile app (iTunes link) does push out news updates regularly, it is also a bit of a letdown. There is, for example, no way to customize when you want to get alerts and which alerts you want to get. You can't just subscribe to tech news, for example, or updates about the latest celebrity deaths.

Still no Twitter Apps with Push

We are also still waiting for the first Twitter apps that support push (at least for replies and direct messages), better calendar apps (Remember Milk is the only one in the App Store so far, and it requires a pro account), apps that can push out alerts when an RSS feed updates or when new email arrives, or apps that are simply innovative and beyond our current exepctations.

Maybe Push Just Isn't the Solution?

While getting the current updates is nice, compared to having to open the app and see what is new, there is so much more that could be done with this technology. But for the time being, either Apple is holding back the most interesting apps, or developers just aren't able to use it in really innovative ideas.

We have talked to a number of companies that are producing geo-aware apps, for example. But because these developers aren't able to remotely wake up an app and pull in data about your current location, there really isn't much that they can do with push notifications at this point.

If only the phone could also run cron jobs, for example. Then that could start an application at regular intervals, in addition to push notifications, and developers could do so much more with this technology.

Of course, we are still in the early days of push on the iPhone, but so far, we have been quite disappointed with the current crop of apps. Hopefully, this will only be a stopgap solution anyway, and by the time the next generation of iPhones comes around, Apple will just allow apps to run in the background.