Disqus - Latest Comments for stevenwillmott

Re: Stepping Back From API Evangelist

stevenwillmott — Wed, 23 Jan 2019 13:48:42 -0000

Thank you Kin for a tremendous run of insights, support, nurturing and all the other things you did for the community. It's been a pleasure to read here and work with you... Wishing you all the very best for the new role and still hope to hear your voice on these topics on occasion!!

All the very best!

Re: When The Companies Who Have All Your Digital Bits Promise Not To Recreate You

stevenwillmott — Sat, 14 Jan 2017 19:05:10 -0000

You bet your ass :)

Re: When The Companies Who Have All Your Digital Bits Promise Not To Recreate You

stevenwillmott — Sat, 14 Jan 2017 18:59:38 -0000

The obvious conclusion would-be that your estate and you should live on after death and collect royalties.. in your will determine what you are willing to do after death...

Re: Lists are the new search — Benedict Evans

stevenwillmott — Mon, 01 Feb 2016 01:05:40 -0000

By their nature the best lists should not be published, they are hard one knowledge which you need need to be in the know about (or pay) to access. A genuinely good list of the top 5 restaurants in San Francisco becomes less valuable when it's out in the open (boy will those restaurants be crowded). Thrillist occpies this grey zone a bit - eclectic lists. They are public, show up in search but there is a little bit of a notion that you need to be a thrillist reader to be in the know.

An obvious model here would be lists of things that change regular (hot new XYZ) that you circulate to paid subscribers ahead of time and publish after the knowledge becomes a little less valuable.

Re: Why I Don’t Celebrate Income Inequality

stevenwillmott — Sun, 03 Jan 2016 11:06:13 -0000

A lot of great points here. It may be that societies have to through iterations - strong social cohesion and levelling the playing field, followed by a period of fragmentation and then another cycle. The social policies of mid last century produced a huge mass of educated people that the last 30-40 years has been able to benefit from to innovate.

The problem with oscillations is you can get stuck in the extremes (e.g. North Korea on the one end) and places where money wields all power on the other.

Paul Graham's article yesterday unleashed the tweet stormer in me - https://twitter.com/njyx/st...

Re: On API Gateways

stevenwillmott — Sun, 05 Jul 2015 21:48:49 -0000

Good to hear that :)!

Re: On API Gateways

stevenwillmott — Sun, 05 Jul 2015 11:06:32 -0000

Good post Howard - Infrastructure needs are evolving fast (even in a single org). I have some bias since we (http://www.3scale.net) are an API Management vendor and also make a gateway, but I agree with your points. (We're one of the biggest players.)

A big part of the problem is actually the conflation of "API Management" and "Gateway" in the way the early market evolved. Putting the "Management" into the gateway doesn't make a lot of sense, since you need Management and you many or may not need a gateway.

The way we did this is our product is that we have an NGINX based gateway (NGINX+OpenResty+Lua) but we also integrate with Varnish, direct into code (Varnish, Node.js etc.) and also with Akamai and CDNetworks. Those different ways to control the traffic layer then connect into a separate management layer which tracks and enforces all the policies, does analytics, provides a portal for developers etc.

That architecture basically means concerns are separated and while our product does it, it's a good blueprint for an in house rollout as well if you're planning that.

Re: Foundry Group Invests in Fitbit

stevenwillmott — Thu, 18 Jun 2015 21:43:08 -0000

Amazing to compare how obvious this looks now v's how completely non-obvious it was to most at the time. Kudos for making that bet (the initial product even wasn't that great). The post bet the team had to execute the heck out of it, which they did.

I like to think we contributed a bit by giving away 500 Fitbits at our API conference in SF in 2013 :-).

Congrats!

Re: The Great Decoupling

stevenwillmott — Mon, 01 Jun 2015 00:51:03 -0000

This is a huge issue. Definitely agree that the solutions in the Second Machine Age are pretty handwavy - the question in my mind is *how* do you distribute the ability to create value and keep it spread. I wrote a bit about that here: https://medium.com/@njyx/te....

Re: Superfeedr : Twitter Firehose shuts down partners

stevenwillmott — Sat, 11 Apr 2015 16:00:32 -0000

Good post - I think it's also stupid from Twitter's point of view - some thoughts on that here: http://www.3scale.net/2015/...

Normally part of the equation on using an API is "is it in the platform provider's best interest to keep serving me". Part of what's messed up here is that it probably is, but they are choosing not to do it.

Re: Finding ROI In Higher Education

stevenwillmott — Mon, 22 Dec 2014 21:12:42 -0000

To get the stats straight: what courses are covered in 4 year college? All or just CS? Since if it's all there's a clear natural bias since coding is a high demand area. Code schools are great, and you can even have a debate about the "value" of some courses (and how they are taught), but it ought to be clear if we're comparing like with like.

Another question asked below is on the entrant pool. How many of Flatiron entrants already have another degree? how many have already held jobs? (The website says "from investment bankers and spinal surgeons to cartoonists and sky-diving instructors. Flatiron"). Sounds pretty different to the school leavers signing up for college courses.

Let's even leave out that it looks like a comparison between a school at the top of it's game and averages across all colleges.

Don't get me wrong - Flatiron looks great, and traditional University models need a lot of work - but statistics need to be clear on what comparison is actually being made -> otherwise they just make the whole argument look fundamentally untrustworthy.

Re: Rise of the Machines: Downfall of the Economy?

stevenwillmott — Tue, 09 Dec 2014 10:33:56 -0000

Interesting and important topic (!) and this covers a lot of ground - however, I really disagree that this is about replacement (at least in the short and mid term): what will work best for a long time is humans and AI working in conjunction - the combination is going to be smarter than one or the other.

The challenge is, how do we give access to this stuff in a usable way to many more people - I write about this a bit here: https://medium.com/@njyx/te... (we have our ages out of sync :)).

Re: 3SCALE Customer Indix Releases Its Product Intelligence API

stevenwillmott — Sat, 23 Aug 2014 10:49:56 -0000

Yes indeed - thanks Cassidy - fixed!

Re: The Valuation Trap

stevenwillmott — Wed, 07 May 2014 21:04:52 -0000

Lets say they had to lay off 30% of the staff - as long as it was done to preserve focus and the core going concern, I doubt the news would even filter much to their users on the street.

It would need to be managed well, but Square is big enough that that kind of fright would not likely kick in too fast. Obviously if they need to make cuts and don't then, that's another story.

Re: From Industrial to Information Society in Five Disappearances

stevenwillmott — Tue, 29 Apr 2014 20:54:39 -0000

note there are two charts... and a lesson in stats in between.

Re: From Industrial to Information Society in Five Disappearances

stevenwillmott — Tue, 29 Apr 2014 20:53:34 -0000

Deflationary innovation in the music industry: http://www.businessinsider..... Yet many more people are listening to music in more places and for more time than ever before.

Re: From Industrial to Information Society in Five Disappearances

stevenwillmott — Tue, 29 Apr 2014 20:50:42 -0000

Great post. A couple of things struck me:

1) the trend to self service is clear: but I wonder if it will reverse, since in theory time is our most valuable commodity - why waste it "self serving". More likely this is a temporary glitch whereby it's still too hard to build something to truely automate a lot of services. We're getting better and better at self service - but mostly likely it'll be to the point that it tends to zero time. On the other end of the spectrum for the truely rich there may be more humans in the loop than before (all that self service to do...).

3) isn't the disappearance of capital - since the capital is just coming from somewhere else - the consumer of the good and paid ahead of time. In some sense this is the increase of capital (a new source which went untapped). This also requires the evolution of stronger protections for those pre-paying in this way.

Ultimately I think these are all a shift from rigid protocols / structures which were hard to deal with but needed to make the world predictable. In their place there is the rise of more loosely coupled system which are being made possible by things like visible reputation, identity, stronger and more flexible person-person transactions. These remove the need for the rigid things we had before.

I think that even applies to attention - it used to be focused into silos: TV channels and be shared broadcast experiences for many people. Now it is hyper fragmented into millions of blogs, online video clips etc. but - there is still a loose social coordination thread: social network connections focus attention in a more loosely coupled way through RTs and shares.

So underlying here maybe a theme of tightly coupled to loosely coupled. During which we exchange our coordination mechanisms for others, but also (maybe temporarily loose our ability to measure things (e.g. disappearance #1).

Re: The Five Axioms of the API Economy, Axiom #2— APIs are core to any cloud, social and mobile computing strategy

stevenwillmott — Sun, 27 Apr 2014 10:31:31 -0000

Thanks for kind comments and thoughts Platformula - agreed Xaas is a nice way to put where this is headed. If Xaas subsumes SaaS-PaaS agreed APIs are the flue for them. In general I think it is that the idea of (remote) components to build you platform or product is really now coming to the point where it can genuinely work.

Re: The Search For The Next Platform

stevenwillmott — Wed, 26 Mar 2014 20:54:19 -0000

Great post, I think this is certainly what this type of purchase is about. However, although I think VR will be huge it's hard to see the platform nature of it - it is above all an interface technology - it's hard to centralize commercial advantage there.

If you want my bet for the next big platform it's say it's the API Economy - which is essentially the Web as a programmable platform. But then I have a bias there.

Re: The lie of the API

stevenwillmott — Tue, 03 Dec 2013 14:39:31 -0000

Hi Ruben,

thanks for the response and pleased to meet you. I don't disagree on identifiability for sure - however you did say "API keys are a Lie" so I guess you were being pretty directly critical! The issue is though what you consider params to be - if you say "no params" and hence no API keys in params" that might be more pure. However, API Keys or some authentication token are going to be needed for many interactions.

You can say "put them in the headers" but that might be worse in some cases. Then you cannot actually post a link somewhere with a key - because to test something you actually need code/a tool which submits headers. [Granted in that case someone is sharing a secret token which they should not do - but it's common]. We typically recommend people allow (if using keys) both params submission of the token and in the headers. People often use the former when testing with a client, the latter in production. If you force it into the header you make it harder for everybody. Authentication tokens or user-ids or client-ids are often needed in some form, so I think taking a philosophical stance that they cannot be in the URL is all well and good but it removes useful mechanisms. Personally when I see http://www.dataorg.org/data..., I have a pretty good idea http://www.dataorg.org/data... is the resource and the para is context.

On the multiple formats treated differently, yes it's an odd situation - but I do think you're being pretty unfair there. The web version was designed for human style usage patterns. The API version is presumably designed for machine style usage patterns (e.g. potentially being hammered by a script - being hammered by many scripts). If you make the human readable version available in a form in which it can also be hammered by a script and then encourage that, you might actually get into a situation where you have to protect and rate limit access to the human readable web version. I don't think anybody is the winner there. You can block an IP address - but then you're killing the very use case you wanted to enable.

It would be great if those resources could be the same and just as simple to use, but if you want machine use you likely need a way to cap volume usage for "general users" to something reasonable and enable much more usage for people with bulk needs.

Re: The lie of the API

stevenwillmott — Sun, 01 Dec 2013 17:31:39 -0000

Good discussion topic and interesting points in the posts. I agree that modern API design often leaves a lot to be desired - there's still a lot of learning going on and mistakes are being made. I also agree that web technologies help more things than some people realize. Having said all that I pretty fundamentally disagree with most of your general points;

1. You seem to suggest that we don't need APIs because we can just retrofit the web and assume the web works the way it does and that'll be ok for API use cases too. Sadly this really isn't true - it may be true for APIs which are general info browsing of roughly the same cadence as human web browsing. But it really isn't when you have high volume data access, bulk operations, realtime push notifications etc. - you need very different setups that expect automated access (that's in addition to parsable formats). Hypermedia APIs certainly have a lot of value- maybe they will even become the dominant way to do API design for a wide range of types: but I don't think making that blanket assumption out of the gate is healthy.

2. API Keys: I think your arguments are really a red herring - an API key is equivalent to a username-password web site: you cant share the link for that either. The fact that the two APIs in question have public web content and closed API content is a choice they made, but that doesn't make API keys inherently a bad idea. That's like saying authentication / private areas of websites are inherently a bad idea. However, in many cases an API does make sense since you want to protect a resource and rate limit usage - software is much more aggressively typically than human browsing - and not just malicious software: it can be a random error in a script - that's a serious issue. For many API some users may want high volume access or access to certain reserved areas you do not want to give to everybody - to do that you need to assign them those rights and establish their identity: hence API keys (or oAuth, or whatever else) - these are important and useful. In the example you give it sounds like it's a negative because the web content is open - but if the institutions wanted they could change this easily: allow up to X hits a day on any URL from any IP address without a key, if someone wants more, get a key. The idea that they must support arbitrary call volumes on JSON endpoints just because the webpages are open really doesn't hold water because people are not writing oodles of software to hammer their web pages today. If they encourage people to do that they may end up having to put authentication on their webpages to prevent the same thing happening - this does not look like a win to me.

3. Websites as they are today are maintained primarily for human use and that has certain implications for their management. The biggest of which is that people fiddle with the structure and break automated systems that are using them. An API on the other hand is managed differently - people are conscious it is being used by software and signal this fact clearly. Even if a website is managed in such a way the structure can be relied upon I would not write code against it - there are no guarantees. If you tell me "here is an API built with web technology" that's a different story - I'll use it. This is not a technical distinction, it is an intent distinction.

So you're not (in my opinion) comparing like with like - which makes the title tend towards being rather flame-baity. I'm with you on good API design, I'm with you existing web technologies being valuable - but I think you're pointing at the wrong failures.

What we need is more / better systems which can be easily accessed and used by software (APIs). What technology is used / how it's deployed is evolving. Even if the technology underlying it is the same - the use cases are pretty different.

Re: 50 incredible stats about the tech scene that businesses need to know

stevenwillmott — Mon, 21 Oct 2013 00:57:56 -0000

I'd say there is a "megatrend" missing - the APIs that underpin all these developments - the number is more than doubling every year, pretty much every major company now has APIs on it's roadmap and they provide the glue for doing business.

Re: Totango takes home CloudBeat 2013′s midstage Innovation Showdown

stevenwillmott — Thu, 12 Sep 2013 00:54:27 -0000

Congrats Totango!

Re: The API-economy is coming and fast

stevenwillmott — Sun, 01 Sep 2013 13:25:10 -0000

Should be a great session - there's very real growth in APIs now and the use cases are diverse: mobile enablement, creating partner ecosystem, allowing customers to integrate deeply and also to support quicker internal innovation.
APIs becoming a must have and so there are also better tool sets emerging - both via vendors and open source. Hopefully that'll yet more APIs.

Re: John Sheehan : How Runscope raised a $1.1M seed round without customers, revenue or even a product.

stevenwillmott — Sat, 17 Aug 2013 03:00:14 -0000

Congrats guys - and good to have more companies in the crazy API world :)!