Thursday, December 31, 2009

The Year in Technology

Year-end got me thinking about all the technology that I've been working with this year. And it's been quite a year! Since this coming year % 10 == 0 it has me tempted to put together a list of the tech I've worked with the last 10 years, but that'll have to come later.

I started the year in the middle of working on a phone application which gets Android SDK up on the list. It was really a pleasurable API to work with, and the coding style reminded me of some of the Java Swing client coding that I worked with in the past.

This year for me was about a huge push into web technologies. In my last startup in SW Architect role I got a solid start in that direction, as I headed up our push into web services (though SOAP and not REST based as this was enterprise environment).

But this year got me solidly doing some development in PHP and CSS and Javascript.

I worked on making my app available through Facebook using the PHP Facebook API and that really pushed me into the ugly details of PHP development.

Luckily on the next project I took on a good friend and colleague pushed me in the direction of Python and in particular using the Django web platform.

A big part of that project was Firefox Extension development which was really fascinating. This kicked up my Javascript development up a big notch, but also interesting in and of itself for understanding how the guts of web browsers actually work.

A couple months ago I became co-founder of a company that is still in stealth mode. Everything I did up to this point was excellent preparation for that.

It's also added a couple new technologies onto this year's list. The first is Lucene which is a Java-based indexing and search technology (no, we're not building a search engine!) which happily has a Python wrapper, PyLucene, which is what I'm using.

Just this week I've been working with MongoDB and it's been awesome. Having worked with SQL quite a bit the last number of years (first Oracle, then Postgres, then MySQL) in an enterprise application environment, building a system on top of MongoDB (using PyMongo naturally!) is awesome.

I'm looking forward to another year of new technology. Especially putting together the system for our new company. It looks to be a really exciting year coming up.

Tuesday, December 29, 2009

Asymmetric contract of APIs

A tweet about APIs that referenced this blog post really raised some interesting thoughts around APIs for me.

The short of the blog post is that it describes how a lone-wolf entrepreneur apparently got screwed over by Google changing their terms-of-service midstream on their YouTube API. The timeline is suggestive of the idea that they might have changed it, in fact, directly because of the work this guy was doing.

This raises big questions on the eco-system around creating products that leverage the API to services that other products provide. This is a big question because use of APIs has proliferated recently, and is clearly a powerful force for innovation and growth.

The APIs provided by Twitter, Facebook, and Google and the services that make use of them are high-profile examples, but of course there are plenty of others.

If you were building a bricks-and-mortar business you'd be able to enter into a contract with a supplier of some service such that it was clear what both of your responsibilities were. Even in the legacy software business, if you buy software from a vendor you can do things like get source code in escrow to protect against them going out of business and that sort of thing.

But in a world where one party makes available some access to a service, provides rules (rightly) against what you can do with that service, and then is able to change that service - the ground could get shaky.

I think what we need is the ability to "lock-in" some terms of service when using an API. The problem currently is that the relationship is completely asymmetric. Company A makes available an API and then can change the legal rules on you at their whim. If you built a business plan around being able to use that API in the way that you used to be able to - you're screwed.

Something like a "Terms of Use" would be useful - as in: "here are the terms under which I am willing to use your API". As I mentioned above, this could be as simple declaring that the Terms of Service for the API user is locked in at some specific time (presumably when the dependent party starts working with it - but there would need to be a formal commitment point).

Things as they are now are too one-sided, and you basically have to cross your fingers that the platform won't change out from under you. To keep driving innovation, I think that needs to change.

Saturday, December 5, 2009

Teamwork

A couple months ago I got an introduction to someone starting a company looking for a technical cofounder, and about a month ago I became that technical cofounder. It's an exciting space, lots of stuff to learn, and a challenging amount and type of technology to implement. Perfect! Still stealth mode, so I'm not disclosing more that that.

It's an awesome time to be starting a company, with more information and advice available now than could have been imagined just a few years ago. I'm lucky too, to be so close to the Boston/Cambridge area and the startup community there. Add to that Twitter and the insane amount of constant flow of information and advice and it is just unbelievable.

This past month what I've enjoyed the most is the teamwork involved in starting something up. The amount of raw information to take in and decisions and tradeoffs to be made when starting something new is great to begin with. Doing all of that as part of a back-and-forth as part of a quality team is outstanding.

I spent the previous year+ working on projects on my own, so this is an appreciated change!

Hopefully I'll be able to share some of my experiences and lessons learned along the way.