Flash channel ecosystem taking shape this summer with litl SDK
Lots of exciting things coming together with the litl OS and SDK. The team has been growing as well as the developer community. A new batch of litl webbooks shipped and many went to developers eager to build Flash channels for the OS. We have a very busy summer planned and we are on schedule for several key evolutions that will turn our platform into the great opportunity for the Flash community we envisioned.
Channel Submission Guidelines
We are close to publishing a checklist of guidelines, both required and suggested items, that developers will need to build their channels by. Like most ‘app store’ platforms, litl recognizes that those who buy our devices are especially buying into a level of simple computing. Guidelines will exist to help developers craft their channels to the standards that we feel our users expect. Another goal in publishing these guidelines will be to attain a level of transparency with our developers so they know what we are looking for in a channel and what requirements to follow that will ensure a smooth submission and review process.
Accepting Channel Submissions
Of course, in order to distribute developer channels to our users, we are implementing a smooth and equally transparent submission and review flow. Developers will submit their packaged Flash channels via a streamlined form. Once submitted, developers can check status of their submission and receive reviewer notes if their channel is flagged for any reason. Once published in the channel store, the submission portal will act as a tracking and reporting tool for developers.
Flash Player 10.1
Although we’ve been preparing for integration since the spring, only recently has Adobe finalized Flash Player 10.1. Our team now is working to apply our custom and enhanced build template to the latest bits for Flash Player. At the center of our integration is video hardware support. We’re also working to fix webcam and microphone access issues that have surfaced with our present/temporary use of Flash Player 10. This team is researching features that will further optimize viewing Flash content on TV, to support the existing HDMI feature on the webbook and our future device, the web-connected TV box.
Launching the Channel Store
At first, developers will be able to submit and distribute free Flash channels. I believe this will create a good foundation of content and establish our ecosystem based on notable and commissioned-channel projects (where Flash developers are hired to build out channels). Certainly, there will be developers looking to establish themselves in the OS. We also have several content partners looking to get their premiere brands on the OS as channels.
A merchant system has been designed, reflective of litl’s simple computing brand, to accept payment from users towards downloading/purchasing channels. We are now architecting this system and a few week’s prior to its launch, we will start accepting paid channel submissions. At this point, we will have further established a very real opportunity for Flash developers to distribute channels to users and actually receive revenue from the sale of their interactive content.
Adding new APIs to SDK
Another piece of the puzzle we are assembling this summer is the advancement of our SDK. As we introduced at Flash And The City, our forthcoming web-connected TV device will add accelerometer, touch and video functionality to the OS. Our SDK team is working on the fun, but complex task of adding these APIs to the SDK code and OS. In conjunction with the opening of the channel store, the new APIs will be key to allow maximum appeal and distribution potential for the channels you develop.
Get Started
Head over to developer.litl.com now and get started with the SDK. Now is the time to learn our simple code and get familiar with the channel development process. As the above pieces come into place, you can be among the first to launch a Flash-based channel and distribute it to our users! We look forward to realizing the potential of this exciting ecosystem.
Twitter making its own apps concerns developers
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.
Flex Example: Populating Value Objects with web service XML
I am working on a little AIR application that stores data both locally (SQLlite) and on a web service (PHP/MySQL) that I’m building in parallel. When the app starts, it requests initial data to populate a pair of DataGrids in the AIR app. I’m sending a URLRequest against a URLLoader with simple params and getting back XML. I am then looping through the items in the returned XML and adding them to an ArrayColletion that acts as the data provider for each DataGrid in the UI.
To bridge the data, I’m storing each item in a value object, so it is easier to reference the item’s properties when viewing and modifying data chosen (and moved around) in the DataGrid. I’m using a nifty trick which seems to be working great for mapping the XML child’s value right to the value object property. Take a look and see if this works for you:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | private function resultHandler(e:Event):void { var resultXML:XML = XML(e.target.data); var items:ArrayCollection = new ArrayCollection(); var item:itemVO; // Convert XML to ArrayCollection for each(var itemXML:XML in resultXML.item){ item = new itemsVO(); for each (var itemProp:XML in itemXML.children()) { //Use XML node name to reference matching property in value object item[itemProp.name()] = itemProp; } items.addItem(item); } } |
Of course, this only works if you create properties in your value object that match the xml nodes you are returned (or that are being returned) from the web service’s XML.
Lots of personal and technical wins in 2009
It’s Sunday morning, January 3, and I’m on a natural sugar high after drinking a cup of Cran-Peach juice from Massachusetts-based Ocean Spray. I wanted to be in the most positive frame of mind (not easy when my Celtics lose 3 in-a-row to end the year / but easier when you wake up to relaxing snow powder wrapped around your house and trees like Mother nature’s cold, yet warm blanket). So here is a recap of my personal and technical wins of 2009, in chronological order…
1. WIN > Successfully and safely relocated my family from the West to East coast.
After just over 3 years in CA, we moved back to and settled in MA. The combination of family, friends and affordability were leading factors. Since both my wife and I grew up in MA, our childhood memories were so engrained that it became too challenging to see us raising our family without the key elements back here we were so fond of. After one year, we are totally settled in our home and are very happy with the decision.
Joining litl
I have left Ribbit to evangelize Channel content and application development on the litl device. This is the 2nd post in a two part story, of where I was and where I am going.
Where I am going…
The love for consumer electronics is in my blood. I was raised as a gadget nutball. My father went to CES every year for something like 22 years straight. I remember him returning with tails of gadgets and new technologies. These were my bed time stories. The technology in our house wasn’t lavish, but appeared essential. My grandfather opened a typewriter sales and repair shop in 1947, fresh off of WWII. 60+ years later, my dad, aunt and uncle run the business as a leading regional consumer electronics and appliance store. We had early access to all the 80s good stuff as it came out. If a dentist’s kids have great teeth, then I had more than my filling of electronics growing up.
After 11 years of coding web applications, I can’t show you a darn thing online. The DOW chart I did for Fidelity.com has long been gone. The widgets Rob Abbott and I worked on for eBay.com and eBay China, while cutting edge, didn’t last past 2006. All the Flex 2 work I did with an amazing team at Yahoo! Maps, an app once used by 40 million people a month, is no longer viewable. [Also gone are my Easter eggs... Shft+F zoomed into Fenway Park.] Even the original code for the breakthrough Ribbit API has all been paved over. These projects represent the years upon years of coding I’ve done. Poof. Gone.
I’ve known for a while that eventually I needed to find a project to work on that would deliver something REAL… something tangible… something you can hold in your hand. I can say quite honestly that I was not actively looking for new opportunities. However, when you get to be doing what I do for a few years and have the visibility that many in our community do, you get contacted by recruiters a lot. When one of those “do you know anyone who is interested in…” emails came across that interested me, I took a closer look.
So, these are some of the key aspects of litl that more than appealed to me. Effectively, here is why I joined the company (in no particular order):
- litl is a device AND a developer platform, with huge potential
I love that litl has the dual opportunity to promote both a device and a developer platform. This should make for a much different experience not just evangelizing what developers can do on a platform, but also talking about the product itself. Effectively, we’re bringing two products to market: 1) the device, 2) the SDK to build/deploy custom content and application channels on the device. Having had experience with startups, I have a pretty good sense of what to look for at the management level. The leaders of this company appear to have the vision and patience necessary to make this a successful venture.
- litl is based in Boston
The last time I worked at a Boston based company was June 2005. I miss the city, its culture and the convenience of catching a Red Sox or Celtics game after work. I’ll still work almost full time out of my well-equipped home office, but having the company’s HQ within driving distance of where I live should cut down the length of my trips (especially to the West coast), considerably.
- litl had the perfect position for me
They were looking for an established Flash Platform evangelist. This is actually my 3rd evangelist role, after Ribbit and Yahoo! Maps. I love engaging developers, giving you new opportunities, and new things to extend Flash Platform with.
- litl is committed to Flash
They’ve already built an impressive Flash developer team, led by the very respected Flash/AIR coder Kathryn Rotondo. As you learn more about litl, and the unique way its channels will allow a streaming web page experience, you’ll see just how essential Flash is. Currently supporting Flash Lite (as2), we’ll eventually roll out a stand alone Flash Player 10 (as3) SDK for channel development.
- litl will create opportunities for the Flash community
There will be an ecosystem for Flash developers to build/contribute custom channels, which will be made available for sale/free, in a revenue sharing iPhone store-like model, to litl customers.
- litl is a chance to evangelize a product-based platform over a service-based platform
Basically, evangelizing a service-based platform, like Ribbit, has some interesting complexities. Beyond the challenge of just promoting the service, you need to encourage developers to get their own accounts, and in some cases, require developers to purchase your service just to work with it. It’s also more about “how does our service work IN your apps?” With a product/device based platform, like litl, it will be more about “how does your application work ON our platform?” The former is more invasive, where the latter is more enabling, I think. [I really owe this concept its own post...]
So, I’m a few days into my new job and love it so far. I had a chance today, at RIAunleashed, to start showing off litl. The reception is great and very encouraging that litl WILL BE an amazing outlet for Flash development on mobile devices, and a break though web experience overall.
Leaving Ribbit
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…
A ‘Catalina Wine Mixer’ of a week ahead
Just a quick post to say that I have a pretty significant week ahead of me. I’m flying out to the Bay Area to check in at Ribbit HQ in Mountain View. After a few quick days of coordinating and catching up with the team, we are all conducting our flagship developer event: Ribbit Developer Spawn. This will take place this coming Thursday night (Nov 5) in San Francisco. I am going to co-host the event, demo some cool stuff and lead a presentation on a brand new SDK offering: a Ribbit Silverlight SDK. As I am pretty new and hence, pretty confused with the new RIA developer environment from Microsoft, I will have some expert help presenting the various Silverlight Controls and Wrapper features Ribbit will be offering the Microsoft developer community.
Finally, and this is as detailed a head’s up I can give, I will be making a very significant career announcement on Friday. Although the timing is odd given the excitement of this week and Spawn, it’s an exciting announcement nonetheless, so stay tuned.
Tickets are still available for Spawn, which you can attend either in person or via video web cast.
Learning Silverlight in the dark
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.
Coding iPhone and Flash Mobile, back to back
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 we see more platform technology roadmaps?
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
Follow Me
Follow Me
Upcoming Engagements
-
