> the company that will win in the end is the one that can ... develop an ecosystem around the product that leads to customer lock-in.
but where should the lines of that ecosystem (for all kinds of custom consumer hardware, from thermostats to pedometers to ...) be drawn? fitbit is definitely making room at the lower end for apps <https://www.fitbit.com/apps>, but it appears <dev.fitbit.com> they want data to go directly from their hardware to their servers before anyone else's code can touch it.
as a developer, of course, it would be nice to get as close to the hardware as possible. i mean, there's no point in releasing the firmware for hardware like this or that nest thermostat since you probably can't even reprogram the things once they're off the line, but could it make (business) sense to have 3rd-party software talk directly to some of these smart appliances, wearable devices, and the like?
there was an interesting comment on the post about amazon buying the washington post, the gist of which was that business strategy is sometimes more about betting on some particular future and preparing for it rather than trying to build an entire future unilaterally. for amazon, the example was ubiquitous tablets; for google ubiquitous internet .... both of which are looking like pretty safe bets. but not everyone can buy into the table where they're gambling on this whole "internet-thing" panning out or not, so let's say you were going to wager on wearable fitness devices taking off. (final flog of the metaphor) where would you place ㅛyour chips?
>> it appears <dev.fitbit.com> they want data to go directly from their hardware to their servers before anyone else's code can touch it.
The way Fitbit works is they push the data down to you whenever it's updated by the device or user.
>> as a developer, of course, it would be nice to get as close to the hardware as possible.
In our case it wasn't desired at all - all we want from the device is the data, which we get from the site. Building wellness products where it's so much easier to have the device automatically upload the phone app (bluetooth transfer) or USB dongle on the users PC. Half your problem is getting people to log into a site every day to record their activity.
Other vendors such as Pebble require the developer to hit an API for the data and their site can be down for days at a time, without so much as a peep out of them. You think as a company they'd want to treat developers better...
but where should the lines of that ecosystem (for all kinds of custom consumer hardware, from thermostats to pedometers to ...) be drawn? fitbit is definitely making room at the lower end for apps <https://www.fitbit.com/apps>, but it appears <dev.fitbit.com> they want data to go directly from their hardware to their servers before anyone else's code can touch it.
as a developer, of course, it would be nice to get as close to the hardware as possible. i mean, there's no point in releasing the firmware for hardware like this or that nest thermostat since you probably can't even reprogram the things once they're off the line, but could it make (business) sense to have 3rd-party software talk directly to some of these smart appliances, wearable devices, and the like?
there was an interesting comment on the post about amazon buying the washington post, the gist of which was that business strategy is sometimes more about betting on some particular future and preparing for it rather than trying to build an entire future unilaterally. for amazon, the example was ubiquitous tablets; for google ubiquitous internet .... both of which are looking like pretty safe bets. but not everyone can buy into the table where they're gambling on this whole "internet-thing" panning out or not, so let's say you were going to wager on wearable fitness devices taking off. (final flog of the metaphor) where would you place ㅛyour chips?