I am extremely proud and happy to announce the launch of my latest project: Mozilla’s Community-Driven Accelerator Program Web FWD. Here’s the release blog post: Today we’re launching Web FWD (Web Forward), the community-driven innovation accelerator from Mozilla Labs. Web FWD supports Open Web innovators by providing a space at Mozilla where they can build their products. We are creating a workshop environment where bold ideas can be realized and bare-bones prototypes can develop and go forward as products.
We’ll host small teams at Mozilla’s global offices for four weeks at a time, giving them access to our people, tools and resources, so they can focus on building. We’re looking for playful, useful, original problem-solving applications and tools that make the Web a better place. During the four week program, teams will work in-house alongside the Mozilla crew. You’ll receive mentorship and guidance from some of the brightest people around, allowing you to focus on bringing your product idea to life . At the end of four weeks, you’ll have a minimum viable product ready to go out on the Open Web. And together we can decide on how to take this product forward.
The program runs on a rolling submission schedule with the first spots opening in August. Head over to the Mozilla Labs Web FWD site for more information and submit your application.
In a recent discussion I was asked which books I would recommend for an entrepreneur to read. My (current) shortlist is in no particular order:
Happy reading. :)
A little while ago I met with a rather large (as in “publicly traded” large) and (despite their size) innovative software company. One of their Senior Vice Presidents told me that they recently started to design all their products (which are mainly for PCs and increasingly for the Web) using the mantra of “Design for Mobile First”. This is an interesting point - during our discussion they pointed out that due to the specific limitations of mobile devices you often end up with less clutter (at least when carefully designed), more to-the-point interfaces (as you simply don’t have the space to mess around). Also - due to the nature of how you use these devices (text input for example comes at a premium) the designer avoids lengthy interactions which further leads to lightweight and simply useful interfaces. The example which was used in our discussion was the website, mobile website and iOS application from the airline Southwest. Instead of me going into details - check this out (it drives down the point pretty nicely): As an exercise - try to find the “Check In” button/link on the web version of Southwest’s site.
One of the many reasons why working at Mozilla is such a fun experience - you get to design your own business cards! (And yes - this is me wearing the Firefox costume at the “5 Years of Firefox” party)
The following is more a snippet / thought / exploration than anything else - just wanted to get this out and put it somewhere…
Hyperlinks allow you to seamlessly browse the Web - clicking on a link in an email inside your webmail client can transport you to an article on Wikipedia which can lead you to a reference on some other website. Hyperlinks provide the glue which keeps the Web together. They link the vast amounts of information the Web has to offer together and allow for one, seamless interaction.
With apps we are silo’ed - none of the apps on my phone, my tablet and for the most part on my computer link together in this seamless way. If a photo app on my iPhone wants to share the picture I just took on Twitter it needs to implement this functionality internally - regardless if I have the Twitter app installed on my phone or not. Developers are forced to reinvent the wheel all the time. Users can’t easily link their preferred apps together (what if I don’t use Twitter but Identi.ca or store my photos on SmugMug and not flickr?)
APIs provide this capability - but they strongly favor a highly concentrated distribution model: As every developer needs to implement each API again and again, developers only integrate with the biggest players in the market.
The future should consists of a simple, unified API (let’s call it - for lack of a better word - the “API-to-Me”) which provides a way for each of your apps to announce which data and functionality it can provide – and consequently consume these services from your other apps. The user agent (your browser) acts as the intermediary - putting you (the user) squarely into the middle of this exchange: At all times do you stay in full control over which apps shares data & services with any other app.
Last week I was lucky enough to be invited to speak at NASA’s Open Source Summit (the first of its kind) about “Lessons from Mozilla”. Now - if you follow this blog you will realize that I give this talk quite often. Mainly because I think that the talk is highly relevant for so many organizations (and please note - the slide deck was developed by Mozilla’s former CEO John Lilly - I am merely the messenger) and secondly because I am really, really passionate about the content. To keep the deck fresh I trimmed the text on most slides, put the whole thing into a new template and made some other edits. Enjoy.
[Update - April 10th, 2011] Here’s the video from my talk.
Most organizations build products. Only some build platforms. Even fewer turn their platform into an ecosystem. The ones who are successful in doing so are the ones who create thriving spaces for innovation and (economic) opportunity. And sometimes you see those organizations starting to compete with their own ecosystem. Which turns out to be a bad idea. Always.
When I was at eBay (back in the day) we decided to open up our API to allow outside developers access to the eBay system. We wrote documentation, we went on road tours to show the world what is possible with our API, we worked with and helped developers to build their ideas on top of the API. Within months we created a thriving, growing, innovative ecosystem of individual developers & companies who created tools which fulfilled a huge need - tools to allow larger eBay sellers stay on top of their sales, inventory, accounting and their customer relationships. Within a short two years this ecosystem grew so fast that a significant amount of eBay items were listed using these 3rd party tools. Then eBay decided to compete. eBay built their own tools - albeit not very good ones, but eBay had the advantage of controlling the access to the customer (which happens to be the same customer our API partners sold their products to - eBay sellers). After a while eBay decided to lower the price of their tools to essentially zero - because they could (eBay made their money by the listing fees, not from selling tools). What happened then was that the market for lower-end seller tools dried up - nobody could effectively compete with eBay. eBay could push their products to their customers - both from a marketing as well as pricing perspective. The result was that innovation in this space effectively disappeared - the tool vendors either went upmarket (i.e. they produced tools which had more functionality and were more expensive) or simply disappeared. eBay sellers were either forced to live with the rather mediocre eBay tools (which they got for free - hooray!) or had to spend significantly more to use the high-end tools. All in all pretty much nobody won.
I don’t know a single case where competing with your own ecosystem proved to be a good idea. Not unless you didn’t have much of an ecosystem to begin with. Sometimes organizations think they have an ecosystem - but really, what they have is a platform which nobody cares about. Then it might be a good idea to build your own products on top of this. But only then.
Simply because I see this happen again and again: Twitter buying and building their own Twitter clients and giving them away for free. Android building an open system with an open market; theoretically allowing anyone to build their own store, but effectively locking people into their own store as it is preinstalled on every Android phone being sold. The list goes on. So - if you find yourself ever in the situation that you have a successful platform which spawned an ecosystem: Don’t kill it by feeling the urge to play in your own ecosystem. You are the platform. Not the player. P.S. Point in case: Twitter tells developers - Stop making Twitter clients [added on March 11th]
Last week I was fortunate to have had the chance to talk about Mozilla and the way we do Open Innovation in a community centric environment at NASA’s Human Health and Performance Center in Houston, TX. My talk centered around seven insights we learned over the years, two problems which stem from the way we do things and ended with a couple of observations of topics which Mozilla Labs finds particularly interesting in 2011 and beyond.
(Please note that the slides and overall concept were originally developed and presented by John Lilly, Mozilla’s former CEO) While being in Houston the NASA folks gave me a tour of Mission Control and their training/mock-up facilities. Which brought up an interesting analogy - the way we run operations at Mozilla Labs is much more Soyuz than Space Shuttle - i.e. we have a solid base, make things up as we need to, generally fly by the seats of our pants and simply make it work (as opposed to a highly engineered and planned effort - aka the Space Shuttle). ;) P.S.: I will update this post with a video from my talk as soon as it becomes available.