This talk expresses my love and intrigue of APIs, demonstrating where I’ve found platforms and APIs in real life, music and things like wiffleball. I have a lot of fun with this one. At one point during this talk, I walk across the stage (or room) and throw various wiffleball pitches at my laptop, with the webcam on screen showing the sharp angles of the ball. This is to demonstrate how my arm is like an API, accepting the arm.throw() call with parameters like grip, angle and speed. I also define a subset of APIs I maintain with my wife and a bonus API-ification of the Delorean time machine.

Of over 40+ presentations I’ve given, this is has become one of my favorites. I’ve given this talk at GeekyByNature (NYC, 3.31.2011) and at NSWG (Newburyport, 9.29.11).

Diving a little deeper, I use examples like the traffic light as ways humans are universally controlled. I also show the asynch event response structure through the way our brain and stomach communicate on whether we are hungry or full. It may seem ‘out there’, but folks in the audience seem to get it very well.

The best part about this talk is the extended Q&A and discussion it leads to at the end. I encourage feedback and questions here, as comments, or to me on Twitter: @chuckstar.

The following are videos that I feature in this talk:

Back in 2005 when the “mashup” craze was really taking off, we were getting reports at Yahoo! about how many developers were using our Maps API. The report was broken down into technologies, web sites, and how many API calls were made from each. Sites like programmableweb.com were busy cataloging platforms and counting how many web sites and developers mashed them up (known today as integrating/extending APIs). Up until recently, many thought successful evangelism meant attracting as many developers to your platform community as possible. The more apps, the more API calls, and the more developers were using your service – extending your brand – calling attention to your service – bringing folks into your domain, and so on.

In some cases, you could see where companies were looking more at their developer totals than the number of quality apps being built on their platform. Not to say this wasn’t a valuable practice. For companies considering developers as customers, the sole purpose of the platform may have been attracting users directly rather than indirectly — through the apps developers built.

But for many companies, this approach ultimately failed. It costs big money to (properly) evangelize to developers, appear at worthwhile conferences, support SDKs in multiple development languages, and adequately power a good performing platform to deliver your service to countless apps and developers.

In advising many companies, I’ve referred to this approach of going out and marketing/evangelizing your platform to any developer as the “butterfly net” strategy. That is, you are going out with a big net to catch as many developers, no matter their ability, specialty or value, and hoping they’ll sign up, download your SDK and use your platform.

Eventually, of potentially thousands of developers, only a few valuable apps emerge. And while the service platform may provide for a nice weekend challenge, the platform may be no match for something out there that can better provide a developer with visibility and even a somewhat easy-to-achieve revenue stream.

There’s been a major shift in the last few years. Developers have become much more savvy in how they spend their time adopting new platforms and respective platform technologies (languages, frameworks, etc). The biggest and most obvious catalyst for this change is the success of device-based platforms like iOS and Android. While structurally different than more prolific service-based platforms (SDKs extending enhancing apps like geo-location, virtual currency, communication, etc), device-based platforms take even more time for a developer to adopt, in principal, and offer a proven incentive to developers — direct sale and monetization of an app. And so, service platforms not only have to be more discoverable to a developer, but they have to present a value proposition that competes with other platforms in a way that almost compliments them.

Many platforms, particularly the abundant and smaller service-based ones, can grow much more valuably now by moving away from the butterfly-net strategy, and align themselves more with traditional business development approach. This can be achieved in a more direct and even cost-effective approach. Instead of showing up with a booth at a conference and trying to ‘recruit’ developers point-blank, platform companies should seek out developers who may have already built apps that will benefit from their SDK. I find it’s easier to answer the question “how can I build this into my app?” over “how can I build an app around this platform?”. The other benefit is knowing the developer is already familiar with — and maybe even a master of — the coding language your platform supports. This, too, saves incredible time in supporting adoption.

I’m not suggesting you abandon the old-fashioned conference appearance. Platforms stories of technology and success still need to be told in front of interested developers. Again, don’t always try and push the platform to a new breed of developers. Try targeting audiences that may be already familiar with your platform, or even developers you’ve already presented to before. And after the presentation, webinar or meeting, listen a little more to those really interested in your service. Schedule time to walk them through docs and examples. See them through the integration of your service and you’ll see an app launched that brings more value to you platform than takes away from it.

I doubt there’s a developer out there who hasn’t been tempted by the mighty powerful marketing forces of device makers calling for apps on their HOT, NEW, COMING SOON device! I should know. As Chief Channel Evangelist for Litl, it was my job for much of 2010 to encourage developers to build apps for a set top box device that has yet to be released. Most devices launch, and when they do, their success can carry with them the talents of the developers and apps that follow.

To a developer, the chance to BE THE FIRST to build an app for an upcoming device and platform could represent the opportunity to have your app get major visibility upon a product’s launch. However, it’s also risky to get involved with a device too early and may or may not be the best use of your time. Due to complexities of the device’s platform, be it varied technologies, add-on SDKs (see below) and other limitations, it’s likely the app you write for one device will need to be heavily ported or fully re-coded if you ever want to deploy for other devices on different platforms.

To help in your assessment of “app for device” opportunities, I have put together a checklist of things to consider before you commit to building an app for a device.

1. What’s the potential market reach?

Apple has critical mass and promotes Apps alongside their products

If you’re expecting to make money selling the app, the device’s distribution is key. You should know from the company that makes the device as much as possible about how many they expect to sell and when exactly the device will reach a critical mass. Also, if you expect the device to be super successful, you’ll need to account for a lot of competition among other apps.

If the company making the device has other, successful products out, chances are they’ll be a success. If this is their first product in the space, it is a bit riskier but the reward for being an early adopter in the space could be huge.

2. Will working with the device’s platform technology add to your skillset?

Good developers love to code, even as a hobby. Even after they’ve closed out their work email, they’re still tinkering with other ‘side’ projects, hungry to learn the next big thing and keep sharpening their skills.

Picking up a device platform could be a great and fun way to cut your teeth on a new technology. If you’ve never coded for devices before, it can really be an enjoyable experience. Also, if you’ve been stuck coding the same language for a while, building an app for a device can lead to new technologies and broaden your horizons a bit.

3. Will building an app for the device be good for your career or business?

If you work at a company, and they are servicing clients interested in a certain target device, then having a deployed app under your belt could be very valuable. Just the same, if you’re a contractor, and have or sense demand from your clients to deploy apps for a device, getting an app out would be great.

In this climate it’s not hard to identify opportunities like these. This might be the best excuse to dive into a platform and not look back. Going into work or sharing with clients an app of yours freshly listed in the device’s respective store/marketplace can be a big highlight for you! So if you’re going to play with a device on nights and weekends, consider one that has great potential for your career and business.

4. Are you over-committing your app to the device platform?

As mentioned above, it’s likely that the app you’ll build may only work on a single device (or with other devices from the same company or platform). If you’re going through the trouble of learning the device’s technology and building an entire app, especially from scratch, consider the effort of having to re-write it for other devices. Many devices share baseline technologies and languages. However, a lot of new ones require add-on SDKs. This means that in addition to adopting a specific language/technology, you’ll need to download and maintain the SDK specific to the device. This can really lock you in and make your app a slave to the platform.

Check to see if the platform has a history of “breaking API”, which requires developers to fix their apps with major API version releases. If it’s a new platform or device, see how frequently they’ve versioned their platform and tools. It might be a sign their going to be trouble.

If you’re using a proxy technology, a method of deploying an app in something other than the device’s native platform/language, make sure that it gives you access to the device features you want to build your app for. Also, check that the company building the proxy technology is keeping up with the overall versioning of the platform.

5. How valuable are you and your app to the platform?

In some cases, your app (and more specifically, having YOU deploy the app) may be more valuable to the device maker than you realize. Dig deeper and find out what incentives the platform support or evangelism teams are offering to encourage you to build for their platform. They may have a fund setup, or more likely, some big marketing dollars to grant you in the name of ‘developer acquisition’. Make no mistake, you’re participation and ability to deploy a quality app is very valuable to them. See what you can get from them (money, free software, and especially, a free device) before you submit your app.

6. Get your hands on the device first or get a first-hand demo or review.

Touching the highly coveted and hyped Blackberry Playbook at CES

More important than the sample code and support you’ll get as a developer, you must know the device you’re coding for is of quality. It must be something people are going to want or need. In most cases, it will help if you also want and like the product. Getting a hands-on demo of the product is very important, especially if it’s not been released yet. This has turned me off of more products than not. It really helps if you believe in the product, and getting to play with the device can boost your interest and confidence in it.

It’s really hard to build a quality app for a product that you don’t have. When possible, you should have the device handy to test with. Platform SDK emulators/simulators are helpful, but with so many different interaction points, ranging from touch response to accelerometer, being able to use your app right on the device can make it so much better. Hopefully, if you’re committed to building an app on a new platform, you’ve managed to get a device for free in the process!

—

I’m not going to list out any devices or platforms in this post that you should jump on or avoid. For now, I’d appreciate your feedback, via comments below, on what factors you look at when assessing a device platform’s potential and deciding whether or not you should build the next great app for it! Most devices coming out are great. Usually, if the company has put marketing money behind promoting it, then it’s likely to be huge! Why not be a part of it?!

My HTC Intredible shipped with a Twitter app built-in called Peep. It was cool, but lacked some polish I enjoy with Seesmic’s Twhirl AIR app on my desktop. Being new to Android, I didn’t realize that features like taskbar notifications were available to other apps — so I was really impressed when I saw a little ‘birdie’ icon whenever someone replied/dm’d/or included me in their tweet.

Days after I got my Incredible, I learned that Twitter, themselves, had launched their own Android app. I downloaded and fell in love. Not only did it beat Peep in terms of usability, navigation and ‘Android’ integration, it also surpasses Twhirl. It’s got me wondering now, when will Twitter put out its own desktop-integrated app (not counting the web site) as an alternative to existing 3rd party apps. And if they do, what will the makers of Twhirl, Tweetdeck and many others have to say about it.

Turns out, Twitter is already fostering some bad blood among its own developer community. Up until now, I think developers integrating Twitter APIs felt they had the franchise on building 3rd party, OS/Desktop/Mobile integrated apps. To see the service company now build/acquire apps and offer them as their own is sending the wrong message to developers. It says, “we appreciate you doing what you did and helping grow our user base to millions. Now let us take it from here…”. This is a dangerous message for a service providing company with an abundant platform like Twitter to send.

Members of the developer community have been voicing their opinions starting around Twitter’s developer event “Chirp” (see
“Tensions Rise for Twitter and App Developers” and “Why is Twitter suddenly making its own apps?“) and you can see there’s something interesting brewing here. I’m interested to see how this pans out. While the ‘mashup’ scene has all but faded over the past few years, building apps around 3rd party APIs remains hot. Other companies who have no intention to compete with their developers, as Twitter seems to be doing, will need to make it super clear to avoid potentially negative comparison.

I have left Ribbit to evangelize channel content and application development on the litl device. In a two part blog post, I would like to share with you the story of where I was and where I am going.

[*]

Where I was…

30 months ago, in April 2007, I walked into the door at Ribbit after leaving Yahoo!. It was a risk. The startup was well into VC funding and had only built a team of just over a dozen talented, yet mostly executive employees. I had a one month old, and my wife and I were wondering how much longer we’d stay ‘re-located’ away from Boston and in the Bay Area.

2 months later, in June 2007, I presented to Ribbit a vision to abstract some very unique internal APIs towards creating an outward facing Flex SDK and developer community around it. They approved, supported me, gave me budget, and I hired Doug McCune and went to work. For 3 weeks, we coded to fine-tune methods (makeCall, getMessages), objects and events (incomingCall, newMessage). For me, this period would be the most exciting coding experience of my career, unlocking never-before-seen functionality to my fellow Flash developer community.

2 months later, in August 2007, I flew to Seattle and presented the Ribbit Flex SDK for the first time at 360Flex. The API introduced a dial tone to Flash Player, and for the first time, allowed developers to make phone calls, send messages and manage contacts from within their Flash and Flash applications.

In the year to follow, we launched the SDK, grew the platform community to over 6,000 developers, worked with Infrared5 (Keith, Chris and team) to get Flash Controls built, and all this culminated when, in July 2008, Ribbit announced it was being acquired by BT. As I revealed in my Flash on Tap presentation this past May, going through all the steps leading up to and surrounding the acquisition were extremely sensitive, nerve-racking, and so rewarding that I only hope my dearest colleagues and friends some day get to experience it.

My job at Ribbit became my 2nd longest stint at any company, and by far, my most successful career move to date. I am very proud of what I accomplished at Ribbit and what the company did together. These days, Ribbit’s focus has shifted and diversified. The novel Flash component that was once our centerpiece is now but a single offering in an array of quality and innovative SDK offerings based on a new RESTful platform. Ribbit has successfully launched their own applications, and now gears up to support both its own users/customers as well as its developers/customers looking to deploy Ribbit in their own applications.

In the 2.5 years I was there, I presented Ribbit to over 60 conference audiences, user groups and community gatherings. This year alone, I’ve flown 36 times, taken 10 long train rides and stayed in almost 20 different hotels. It takes a lot of dedication and passion to travel around the country and across the pond, promoting the virtues, innovation and excitement of your company.

My decision to leave Ribbit is based on mostly personal factors. I’ve found success working with Flash Platform technologies and the amazing developers in that community. To successfully evangelize technology, you need to both wrap your head AND your heart around it. While I found it thrilling and interesting to enable dial tone and telephony development with Flash, the idea of doing this for other technologies just didn’t excite me as much.

To my colleagues at Ribbit, I wish you all luck as the company grows and continues to succeed. To my developer community at Ribbit (now over 16,000 strong), may the ever more diversified and stable platform provide all that you need to produce industry-leading, communications-enabled applications.

Lastly, in saying goodbye to the world of Ribbit, I am also closing a West Coast chapter in my life and career. Tomorrow, for the first time in 4.5 years, I will check into work at a Boston-based company. I’ll reveal details on my exciting move to litl in my very next post…

Dear Microsoft,

I’m a career long Flash designer and developer. I have used Flash Professional and Flash Builder (a.k.a. Flex Builder) just about equally now, over this time, which means I’ve spent about the same amount dragging/dropping/drawing symbols in Flash Pro as I have writing AS/MXML in an Eclipse environment. I’ve approached projects starting on both ends of the workflow, as a designer building a prototype, and as a developer applying code and framework to existing or non-existing designer assets.

A recent new project at my job prompted me to learn and begin working with your Silverlight products and platform. Here are my notes, some suffering points, some compliments, and overall suggestions for how to improve your relatively new process for building RIAs.

1. What’s with the extremely long install process? Why is it that in order to install Visual Studio, I had to download an .iso (not an .exe like most installable software), then burn it on to a write-able DVD, then install it? Is this a process that your existing customers have told you they enjoy? Even after the download and burn, which took several hours at Fios speed, the install process took nearly 3 hours by itself. That’s right. To install Visual Studio 2008 SP1 on Vista, it took way too long. [Visual Studio 2010 beta took even longer.]

2. After figuring out what Silverlight SDKs and toolkits I needed, and where to find them, I downloaded and installed each of them — another very long process. Upon launching VS 2008 and going to start a new Silverlight project, I was hit with a deadly show stopper. VS 2008 would prompt an error “Object reference not set to an instance of an object” and then crash.. each and every time. Now, I posed this issue to several of my “.Net expert” colleagues, and each assumed I was missing some aspect of the Silverlight SDK/Toolkit install process. Turns out I was not. After searching (via Google) for the error, I found a helpful hint on a random blog (GeekswithBlogs.net) which gave me instructions to run something from the command prompt (devenv /resetskippkgs). After restarting Visual Studio 2008, this did the trick. Thankfully, and unfortunately, the issue covers Siverlight 2, although I experienced it working with Silverlight 3 as well. Now, this seemingly undocumented/unofficial ‘fix’ was very hard to find, so I was left wondering if these are things the experienced C#, VS or Silverlight developer just knows…

3. This next one I can’t fault you on, but it was confusing to me nonetheless. Working with Dlls was very awkward to me. The concept that I need to not just import (using…) a namespace/class library, but literally install an ‘assembly’ into my project seemed a bit strange to me. This process seems somewhat close to working with SWCs, but just a little beyond the bubble of what made sense to me. As a lifelong PC user, Dlls were always those library files that accompanied .exe’s when installing software on the PC. Now using them to add features, framework and tools to my project just seemed rather extensive. I realize this is a longtime standard practice, but for the newbie, was hard to wrap my head around initially. Perhaps some more documentation and examples on the what and why of this process would have helped.

4. I found out the hard way that the ‘Toolbox’ in Visual Studio 2008 (and 2010) is useless. It just doesn’t do anything for me. Sure, I like all my available tools and Controls listed, but what good is dragging and dropping tools into my code if they don’t come with some initial properties for display, event handlers or other functionality? VS assumes I know how to work with the Control, which is far from the case. Furthermore, there seems to be no publicized Control browser/view, which helps me explore properties of the Control/tool, how to customize it, etc.

5. Along the same lines, I found out the hard way that the Silverlight authoring flow changed in the middle of my projects. When I first installed VS 2008 (and 2010), inline Design view was part of the workflow. Just like FlashBuilder (in Eclipse), I could toggle between code/source view and Design view, if only to validate that my app’s layout was right on. Aside from never really understanding nor getting the Design view in VS to work, it seems that option is now all together eliminated. Now, I must simultaneously run Expression Blend to work on my layout and validate in Design view. Why can’t I do this in the same IDE? Were folks complaining about performance or having too capable a single authoring environment?

5. Again, along these lines, the whole code behind thing was not new to me, but took a while to get used to in your environment. It just seems that having two classes, one for layout and one for code is a bit arbitrary, especially for simple applications and examples. This necessity, which I’m assuming goes back in time way before Silverlight, seems to add further dependency on the need to work with both Expression Blend and Visual Studio to get things done right. Now I realize that in the big firm, you may see it as design being done with one tool and code being done/added with another tool. But, for the one man band that is me, in this case, having two apps open, worse yet, THE SAME PROJECT open in two apps, is a very weird workflow. I had to get used to seeing “this file has changed in another application” way too much.

6. I got caught in the void between Silverlight 2 and 3. Looking for books and references online, it seems there is way more written and blogged about SL2. Yet, your site and everyone in your community tells me SL3 is now the defacto way to build SL applications. Why is there such a lag with getting new examples for SL3? I’m surprised that all those early adopters who put out SL2 examples are so behind in updating those to SL3. It’s hard for me to tell which SL2 examples to ‘trust’, not knowing really what does/doesn’t translate from SL2 to SL3.

7. One thing I like about working with Visual Studio is the ability to launch multiple instances of the app. With two screens, which I truly hope the average MSFT developer has, it makes it easy to compare code from multiple projects by viewing both at the same time.

8. Another thing I like is the debug environment inherent in Visual Studio. Breakpoints are easy to work with and the stack dump is very easy to navigate when trying to figure out how to parse XML/JSON for the first time. It’s too bad that the IDE locks up (for me, anyway) when I’m in debug mode and that, upon stopping the debug process, I lose this stack as a reference when I’m further coding my app. Something tells me that there’s a way to sustain this view after debugging, but I haven’t figured it out yet.

10. While I have issues with the separation of Expression Blend functionality from Visual Studio, I do think it’s a very tightly designed product. The interface to toggle control layout, size, color, etc, is very clean and intuitive. It responds well, and generally, what I see in the IDE is what I get in the browser.

In closing, I realize that much of my issues may be a result of my not being a seasoned Microsoft and/or C# developer. Perhaps those familiar with your workflow and tools can find their way in and out of these shotgun issues much easier. I consider this, but then realize, aren’t you going after developers just like me? Aren’t you looking to give me a broader choice of tools and platform when I need to deploy a rich application?

Perhaps my situation is a bit different. As a platform evangelist, I’m not really evaluating your product, nor am I choosing what’s best, for my customers. Thankfully, for your case and mine, my customer , in this instance, is already your customer. In other words, we’re deploying a new SDK for your existing developers, so I’ve got to figure out not only how to develop in the Silverlight environment, but figure out best how our service fits in from both a practical and instructional perspective.

In closing, I hope what I wrote here helps you make your product better for your existing and future users. Don’t dumb things down on my account, but understand that not everyone installing (rather, waiting for the install process to complete so they can use) your tools knows them well enough to get themselves in and out of your workflow with ease. Lower the barrier of entry and you may appeal to, and more importantly, enable, a lot more folks. This may be hard for you, seeing as your existing and historic developer contingent has already adapted to what I think is a very hardcore centered developer process. Creative people need free flowing tools to put their ideas in motion. They need to express themselves in their own why, so you may not be able to ‘blend’ it easily with what you already have.

After spending the bulk of my ‘personal coding time’ over the last 6 weeks on building my first iPhone game/application, I’ve moved on to another mobile coding platform. After 6 weeks of learning Objective C and Xcode (also my first time coding on a Mac), I’ve jumped back in time to a mobile platform called Flash Lite. Pretty insane. It’s a mobile coding mind bender. The developer’s equivalent to a gender transformation.

These are completely different platforms, and the approach, ‘vibe’ around them, and outcome couldn’t be anymore different.

With the iPhone, with each compile & build, seeing and feeling the app load on a my sleek iPod Touch, I felt like I was an Olympic swimmer, making a sleek dive off a precision diving board into a crystal clear pool surrounded by people sunning themselves and drinking vibrant cocktails.

On the other side, cracking open Flash Professional, coding archaic ActionScript 2 and compiling into the Flash Lite simulator they call Device Central, the experience was much different. It feels like you’re climbing up those wet and slimy stairs of a pool slide, making your way down the insufficiently watered and windy curves, somewhat burning your skin on the sides of the dry plastic, before getting dumped into a pool of a few senior citizens floating on foam noodles and sort of applauding at me.

Strangely… I still really love the latter experience. Why? Because it feels unique and un-crowded. The stuff I’m doing seems far more untouched, less shiny, yet way more revolutionary. And the stuff I build with the latter process can be published to a comparatively infinite number of brands and devices. The same Flash Lite (FP6 level) .swf I coded co-exists on both a Chumby, as well as my Sony PSP. (Pause for a second and imagine that. Two companies, produce two devices, meant for a much different purpose and market. Yet, they are bound by a common mobile platform that tells me, the developer, that I can WRITE ONCE!] I haven’t even tried my Flash Lite app on actual mobile phones yet. The thing is… I don’t need to. I know what I’ve done and accomplished. Feels good.

The app I built will be demo’d at http://developer.ribbit.com/blog in the near future.

While the process still needs a lot of help, I can see how Flash Lite (soon to be much grandeur Flash Mobile development) still has a huge place in this mobile application movement. And now that I’ve had my moment with Flash mobile coding, it’s back to iPhone to build another app that I hope thousands will enjoy — at Apple’s discretion, of course!

Why don’t more technology platforms have published roadmaps? A product roadmap, in this case for a company’s platform offering, would be a detailed list of fixes and new features in upcoming releases/revisions of the platform. In its most comprehensive and impressive form, the roadmap will include future release dates, version numbers and even advanced documentation on method signature and event changes.

The benefits of a published roadmap could be beneficial to both the company and the developer/user community. Yet, it’s a rare thing to see a roadmap of features available for your platform of choice. Here are 5 possible reasons that a company (or engineering team) wouldn’t publish roadmaps:

1. The company doesn’t know or plan releases. Amongst platforms that I would love to view roadmaps of, I really hope and doubt this is the case. How could a company not know what they are working on in terms of new platform features or fixes? I suppose there has to be some out there that wouldn’t publish a roadmap for this reason, but it’s got to be the last possible reason.

2. The company has low confidence in engineering team. Probably and sadly a bit closer to reality, the company may have a tough time keeping to previously released schedules and as a result, has little confidence in its engineering team to deliver on time. There are other factors in the release process such as sufficient resources, timely QA, scope creep and such. Still, to find yourself in this situation is not good.

3. Admission of guilt. If you publish a list of ‘bugs to be fixed’ too soon, it may show how many flaws there really are in an existing release and force your users/community to lose confidence in the current (and possibly future) release of the platform.

4. The company fears competition will steal their thunder. I’d like to think this is the most frequent reason you don’t release a roadmap. Should you announce your plans to early, via a published roadmap, of ground-breaking new features, you may open the door for your competition to take on those tasks as well. Keeping new features close to your vest can prevent this.

5. Avoid hesitancy of adoption. If the roadmap were to reveal new features or easier/improved ways of doing things, the community may hold off adoption awaiting the better release thus slowing adoption and growth of community.

Again, I think even with these reasons/excuses, companies should make every effort to publish their platform roadmaps. Your users are vital and likely high spirited about your product offering. Keep them in the loop about your upcoming releases, solicit feedback when possible and give them a chance to tell you what should be fixed/improved/added in your next release.

Do you know of any good platform roadmaps out there?
Ask your platform company of choice why they don’t publish their roadmaps.

As a platform user and evangelist, I want to see more!

For reference, here’s a great example of a platform roadmap: http://source.android.com/roadmap