This morning, Mapbox announced a $52.55 million Series B financing. We’ve been on a wonderful ride with them ever since we led their first financing – a $10 million round – in October 2013.
Let’s start with the simple stuff. My partners and I have a massive founder crush on Eric Gundersen, the CEO of Mapbox. My partner Ryan McIntyre was introduced to Eric by another CEO we’ve backed, Zack Rosen of Pantheon. I remember Ryan raving about Eric and pushing me to squeeze in a meeting before I had to run out of town one day.
Zack is also a total star who I connected with immediately so his referral carried a lot of weight. I first met Eric in the summer of 2013 on a trip he took to Boulder to buy imagery from a satellite company in the area. I remember feeling super rushed at the end of the day and wasn’t in the mindset to sit through a presentation. Eric clued on in this immediately, or maybe Ryan warned him, so rather than drag me through slides Eric just started showing me stuff that Mapbox did.
He started with an algorithm that made clouds go away. He then launched into a custom map design tool which Foursquare had just used to switch out Google Maps. By this point my jaw was on the floor. Words kept tumbling out of Eric’s mouth and amazing maps kept appearing on our large conference room monitor. I looked over at Ryan and he gave me that “yup – I wasn’t kidding – this is fucking awesome, isn’t it” look that we share between ourselves when we see something beautiful, incredibly hard to do, presented by an entrepreneur who is completely and totally obsessed by what he is doing.
I knew Gnip was doing some Twitter data visualizations with Mapbox, so I asked Jud Valeski, the technical co-founder of Gnip, to see what he thought. Jud responded with something akin to “Mapbox is amazing.”
Even better, Eric and team had been at it for several years bootstrapping development and had just decided to raise their first outside capital. They had done this amazing amount of stuff with no investment. No hype. No bullshit. Just crazy deep tech abilities.
In 2013, the mapping space was in yet another wave of turmoil. Waze had been snatched up by Google for over a billion dollars just a few months earlier, further consolidating a space dominated by a few giants. Those giants were investing billions a year in maps. And we were still getting over our fresh scars that confirmed how hard the geo technology was after our failed investment in SimpleGeo (acquired by Urban Airship). Mobius, our prior firm, had been a long time investor in deCarta (now owned by Uber) and had been mostly recapped out of the investment after years of struggle. So mapping didn’t feel natural to us.
But in 15 minutes of watching and listening to Eric, I realized something Ryan already knew. Mapbox is an API company, not a mapping company. The map simply was the output of the API. And, like the best API companies we’ve been involved in, such as Gnip (now part of Twitter), it was right at the intersection of our Glue theme and our Protocol theme.
Seth and Jason had similar reactions. So we invested. Since then Eric and team have built an incredible company that is the foundational building block for any developer, large and small, who wants to include mapping in their product. In case there is any question about scale, MapQuest, which still has 40 million active users, confirmed it was switching all of their maps to Mapbox.
Eric and gang – we are buckled up and ready for the next part of the ride!
Update: Cards@fullcontact.com is no longer available as FullContact has integrated this into all of their consumer applications. The simplest approach to doing this is now FullContact CardReader.
There are some things I wish would just go away forever. Business cards are one of those things. I stopped carrying them several years ago and simply give people my email address (brad@feld.com) as my primary contact data. But at the end of every day I have a handful of cards to deal with. Sometimes it is one or two; often it is a big pile.
Yesterday I was at the Xconomy Big Data Conference in Boston. I was the lead off keynote speaker so I decided to spend my 30 minutes doing a rant on Big Data that I started off with the line “Big Data is Bullshit.” It was fun for me and I hope useful for the 500 people in the audience.
I ended up with 20+ business cards from people who I talked to in between sessions. During the afternoon, I took a photo of each of them with my iPhone, emailed the photo to cards@fullcontact.com, and then tossed the card in the trash. I now have a photo of my card on my iPhone and due to the magic of the FullContact CardShark API the data was automagically turned into a vCard and a Google contact. I got emails back with each card, clicked one button on the email, and voila the contact data was in my Gmail Contacts data.
My friends at FullContact talk about how they do this in their post If Only CardMunch Were An API… Oh Yes We Did!. When CardMunch first came out I was a happy user. I struggled some with quality, but put up with it because it was better than the alternative. I stopped using it about six months ago due to reliability and the overly tight integration with LinkedIn at the exclusion of other approaches.
@mattdelliott and @travis_todd created a replacement for me (and for you) at HackDenver in 6 hours of codings. Literally all you do as an end user is:
Boom.
If you are a web developer in Boulder who does stuff with APIs, I encourage you to join our friends at Singly on Thursday 7/26 at the Bitter Bar from 5:30 – 8:30. They are building an organic network of friends and evangelists around APIs and looking to have a conversation with anyone interested. Several Foundry Group companies who are API-centric will be there including FullContact and SendGrid are co-sponsoring the event and helping to promote it.
When: Thursday July 26th
What: APIs and IPAs. Free drinks and appetizers; Sign Up Here
Where: Bitter Bar Boulder | 835 Walnut Street | 5:30pm – 8:30pm
Singly is an API abstraction layer and data service for developers who are building apps that consume data from multiple authenticated/private social data sources. They handle/unify auth, data syncing, unified access patterns for query, cleaning (deduplication, etc) and storage. In general, they are seeing more apps being built that are “smart” apps that create new data/experiences drawing from the growing body of already generated data/experiences and are aiming to make it increasingly easy and cost/time efficient to do so.
It’s 2012 and the “contact information problem” is getting exponentially worse. I’ve personally been struggling with this for 20+ years since I remember going from a custom database we built at Feld Technologies (in DataFlex) to Act! to try to manage the contacts across the company. While all the technology has changed, the problem has gotten substantially worse, as every web-based and mobile app now has some kind of contact info associated with it.
Today, there is no single authoritative contact record for an individual. I’ve been through a bunch of different iterations of technology around this such as SAML, FOAF, and Oauth. I remember Firefly and Passport. I’ve been involved in a number of companies who have tried to build “clean contact lists” and tried virtually every service I’ve ever run into. I’ve completely fucked up my address book more than once, especially as I tried to wire in data from other services that use Oauth or an email address to join data across web services. And yet we still have address blocks in emails, vcards, and crappy, incomplete, and incorrect data everywhere. And I still get referred to as Brad Batchelor in physical mail that I get from Wellesley College (which both Amy and I think is cute.)
Nothing works and it’s just getting worse. Fragmented data, incorrect data, changed data, duplicated data – it gets proliferated. All you need to do to see the core problem is look at the same data for a person in LinkedIn, Twitter, and Facebook. Multiple email addresses, lots of different contact info, time-based information that isn’t treated correctly, and huge errors all over the place.
That’s why we’ve invested in FullContact. They are on a mission to solve the world’s contact information problem. Imagine a unified address book in the cloud that has perfect information for every single person with a contact record of any type. This unified address book is continually updated, cleansed, enriched, and validated. It integrates with every web-based or mobile application that uses any sort of contact data, and it is available to every developer via an API.
This is a massive data problem. The team at FullContact is approaching it as such. It’s one where the machines do all the work and don’t rely on us silly humans, or the IT people, to change behavior and systems. For a look behind the curtains watch this short example from FullContact’s Identibase.
If you are a developer, FullContact’s goal is for you to use their cloud address book via their API. If you are an individual, you can use the FullContact cloud address book as your source address book. And if you are a business, you can finally get a unified contact management system across your organization without having to do very much. Data will automagically get cleaned up, enriched, de-duplicated, validated, and backed up, making it easily accessible in any context.
We’ve gone after the world’s contact information problem a number of times in a number of different ways over the years with different investments. We’ve never been involved in conquering it and it’s just gotten worse. This is the first time I feel like we are investing in the right approach to solve the problem once and for all.
Oh – and we love the team. If you want a fun view of why, take a look at From Basements to Brad Feld: The Story of 126 NOs and 1 Big YES.
I love Fitbit. The product is great, the team is great, and I’m psyched to be an investor. I’ve been a user for a while – my data is public – but I just recently started using the food tracker which is superb. The only thing that was missing for me was an API.
Fitbit released the Fitbit API quietly a month or so ago. I’ve encouraged them to make more noise as some great applications are coming out. I use two of them – Earndit and the Fitbit Low Battery Notifier by Joshua Stein. There are a bunch more coming but I thought I’d encourage any of you out there who care about human instrumentation to take a look and consider integrating with Fitbit.
And, if you want the best fitness and sleep tracking product in the universe, go take a look at the Fitbit.
My friends at Orbotix are hiring. Following is the list of open positions. If you fit the description, like playing with robots, want free beer all day, and live in Boulder, email them a note with a resume.
– Game Designer: Are you passionate about gaming and have a deep understanding of game design and game mechanics? This isn’t a programming job but you will need to be able to create wireframes and rough graphics for games that bridge the gap between the virtual world on your phone with the physical gameplay aspects of Sphero.
– iPhone Game Developer: Build amazing and crazy iPhone games that integrate with the Sphero API.
– Android Game Developer: Same as the iPhone developer but on the Android side.
– Social Media & Marketing Manager: Do you love robots, toys, and games and can think of nothing better to do than talk to people about them – both in person and on Twitter, Facebook, and a blog? If yes, then this is you!
– PHP Developer Internship: This paid internship is for someone fluent in PHP development who can help manage the Orbotix web sites.
– Marketing Internship: This paid internship is for someone who will be working with our marketing manager to promote Sphero.
Orbotix has some exciting announcements happening in the next 30 days; if you’ve been waiting for the right time to join a hot startup in Boulder, now is the time. And, if you are at SXSW, go hunt down the Orbotix gang and participate in their “Where are my balls?” contest to win a free Sphero.
I’m at the Glue Conference all day. So far, it’s far exceeded my already high expectations. I’m now sitting in the API track and the first two presentations have been dynamite. Clay Loveless from Mashery just did a presentation titled “5 Things I Hate About Your API-TOS“. He nailed it. Here are his top five (most important last), along with some commentary from me.
For simplicity, I’ll call the company providing the API’s the “platform company” and the companies using the API as the “ecosystem partners.” Also – I’m not picking sides here as I’m an investor in both “platform companies” and “ecosystem partners”. Rather, I’m just trying to summarize Clay’s points, bring out a few ideas, and give you a sense of the kind of stuff we are talking about at Glue.
5. Do You Think My Code is Yours? While it may seem like a stretch that a platform company trying to create an ecosystem would try to assert this, the phrase “derivative rights” appears in a surprising number of platform company API’s. And I’ve run into people that actually believe they own the code (or rights to the code) developed by their ecosystem partners. The only thing I can say to this one is “be careful and don’t accept absurd assertions.”
4. It’s Just Tooooooo Loooooong. This one is related to the next one, but it’s what happens when the lawyers take over. See #3.
3. It’s Written in Legalese, But I Speak Geek. Thanks for the 14 page TOS – now what the fuck does it mean? Give me a one page summary in plain English and bullet points. Be “ecosystem friendly” – all the time. Don’t bury the lead on page 11. Just tell me the rules so I can play by them.
2. Commercial Use OK Or Not? I’m seeing this become increasingly contentious between some platform companies and their ecosystem partners. Until the platform company is successful, this is a mellow and happy situation. Once the platform company becomes successful, often in part to the adoption of their API by their ecosystem partners, the platform company starts trying to split out commercial and non-commercial use, at least in certain areas. If you are an ecosystem partner and you think this evolution should be against the rules, just check page 10 of the TOS (per point #4) where it says “Company reserves the right to change any aspect of the TOS at any time in the future.”
1. TOS != Product Roadmap Communication Platform. As an ecosystem partner, you should assume the platform company will change its roadmap over time to support its business goals. It can be painful when this happens in the context of a TOS change, although I think there are some cases where the platform company just has to say “ok – here’s how we are going to do things going forward – deal with it.” The solution to this one is clear and open bi-directional communication – as long as there is trust and no one is trying to hide the ball or do things that are clearly “over the line” in terms of the TOS, these situations are usually quickly resolvable with an appropriate commercial agreement.
Oh – and if you want to run Java on an Apple IIc, here’s how you do it.