Am I unfairly picking on Stewart

I’m taking time off on this Daddy day to respond to Tara Hunt and to continue this meme flow.

Here’s what Tara left as a comment:

C’mon Marc. Stewart isn’t the bad guy here. Tell me you can honestly say that if that Tate kid didn’t directly benefit from this little cause of his, he would say anything at all. Ask him where his export tools are. A little tidbit, Stewart always encouraged Riya (and never blocked us) to build those tools, even encouraged us to crawl their site. That doesn’t sound closed to me.

It’s not - and you’re right Stewart has CLEARLY been one of the leaders - if not THE leader in this area.  Bradley also has proven over and over again how open Yahoo is willing to go.

And I don’t know this Tate kid - from a hole in the road, and he NEEDs to have HIS export tools in place too - or shut up - but that’s the goal here - right?  That open means a two way street.  

When I go to MySpace and tell them that their data is leaving ANYWAY cause of scraping, we need them to realize that they need to put in wires - so that their end-user’s data can flow in BOTH directions.  So too with everybody.

All the more reason why its important to make a statement here.  You can’t be open on a case by case basis. Flickr can’t choose to work with Riya, but not Zoomr.  That’s just not fair. The whole basis of being open is to let the end-users decide - based upon features and funtionality, not perpetuated lockin. If a social networking web service vendor approached me - and said: “Marc - we got these open APIs we want you to support so we can export out your end-user’s data” - I’d say yes.

If a competative social network white labeling vendor approached me and said: “let’s standardize on templates and skins” - I’d say yes.  Now of course I’m saying this the vantage point of being a broke, nobody, has-been, used to be famous schmuck.

And Stewart has to deal with being famous, rich, working for Yahoo and driving a train that the whole world is watching - so arbitrarily saying “we’ll work with Riya, but not Zoomr” - just doesn’t seem right.

The only rule that works is “if you’re open, be open - and create a two way street”. If the data leaves it can also come back.

If you don’t want to play by the rules, that’s OK too - but lets keep it real.

That’s why we’re not GPL, and we took all the GPL code we were using OUT of PeopleAggregator.  Cause we weren’t willing to play along by the terms of the GPL license.  That’s also why we DON’T call ourselves “open source” - even though our source code will be available.

Because the official defintion of open source says we can’t sell it - ever.  And we ARE gonna sell our code - to commercial vendors.

So how can Flickr call themselves open, and how can Stewart sleep at night - after ALL he’s done - and just decide to shut off the valve to folks who are coming in - just a little bit too close. 

Stewart used the example of Buzznet and working with Buzznet in the early days of Flickr.  Well that helped him out - at the time - as Buzznet was ahead of Flickr. But now that Flickr is ahead of Zoomr, he’s gonna change the rules - in mid-stream?

I just don’t buy that.

BTW in closing - I wanna share with you a letter I received this morning from Mootatis Mootandis:

Hello Marc,
I was most impressed with your work regarding PeopleAggregator, but would like
to ask the following question - Have you and your company devised a strategy
for the design of average-joe “UIs” to the vast network of APIs you’re about
to supply? After all, APIs aren’t for everyone, and it is the “everyone” which creates
the actual network.

This is exactly the point. [Thank you Mootatis - well timed!]

We need to put simple user interfaces in front of these APIs to make them usable by humans.  We can’t do that on a case by case basis. We need to build UIs around standards - so for Flickr, Buzznet and Zoomr - there are the obvious commands like: “get image, send image, look for tagged stuff, find group, etc.”

All these APIs need to standardized across each domain area - and then we (as an industry) can start delivering the ‘average Joe and Jill UIs’ that Mootatis is asking for.  Its that simple.

But if we start excluding certain vendors, start playing favorites, start acting like certain conference vendors - who pick the same dam inside crowd every time to speak - then we’re really no different then Web 1.0.

For the Lve Web to succeed (credit to Alan Searls for that term - trademarked released for anyone to use) - we all need to work together, not exclude certain competitors ’cause they’re coming in to close.

6 Responses to “Am I unfairly picking on Stewart”

  1. Kristopher Tate Says:

    Hi Marc, thanks for picking-up on all of this.

    Trust me in that I want to make sure everyone has access to Zooomr’s data at some level or another. I’m all for swapping API keys with Flickr (and any other entity, for that matter) and hope that in the end, users get a richer, more seamless experience from open standards.

    If you would like to get to know me, please drop me a line — I’d love to discuss things further with you.

    More anon,

    Kristopher Tate
    cto & founder — bluebridge tech / zooomr

  2. Stewart Butterfield Says:

    Yo Marc, I don’t think you’re being “unfair”, but I do think you’re missing some of the subtlety here. I’m just going to cut and paste (from an email I wrote to Dave Winer, which he ignored) since I’ve already written all this out a few times, but I’d appreciate it if you could take the time to think it through:

    The issue isn’t so much letting people get their data out (we already do, and always have), nor is it specifically “making it easy”, but granting direct competitors (especially those with short or unknown track records) the ability to proxy for users’ login credentials.

    I don’t know if you’ve ever looked at our authentication API. Basically the way it works is that third parties send users back to Flickr to check if they want to give the third party the credentials necessary to authenticate via Flickr on the users’ behalf. If they say yes, the third party gets an auth token for that user, tied to their API key and auth secret. Then they can call authenticated methods via Flickr’s API — essentially, they have the ability to login on the users behalf and do all kinds of stuff.

    For partners or independent developers doing something complementary or any number of other, we eat the risk of them doing something bad with the API. For competitors, it’s harder to scrape together that trust. For competitors with no background or track record, it’s even harder. Imagine an app that deletes all your stuff off Flickr after importing since “you’re done with it”. That kind of sucks for Flickr, but it REALLY sucks for the user, and we’ll take the blame for it.

    But more importantly, who gets API keys is kind of a red herring because custom implementations of vendor-specific APIs are not the path to true interoperability. Given your background, I’m betting you understand exactly what I mean. I wrote about that on Flickr:

    That’s why you download an OPML file and upload it somewhere else. More generally, that’s why there .csv format, and XML all over the place, a zillion IEEE, ISO, ITU and IETF standards, and things like EXIF, DOPF, ITPC and XMP for photos. That’s why you export your blog from one service and import it to another.

    And that’s why I was talking about embedding information in the jpg files - the only way you get real interoperability is with a standard. Most people with digital cameras use their PCs to manage their photos. What are the chances that Microsoft builds a Flickr API-based Flickr importer into Windows or Apple builds one into OS X? Or Adobe Photoshop Album, Picasa (the desktop client), ACDSee, Jasc/Corel Photo Album, Thumbs Plus, iMatch and the dozens of others do the same? Would all of them start coming bundled with web servers? Are we going to implement an import service for each of them in case someone changes their mind after making some changes?’

    Anyway, there you go. We go way, way out on limbs all the time for users and we will continue to do so. We’re not trying to lock anything or anybody in. You said I’m “ignoring the interests of [my] customers” and that just ain’t true. There have been Flickr export tools since the beginning and we’ve never tried to stop anyone from making them (in fact, one of our employees developed one on the side and stuck it in CPAN). And we have zero interest in preventing a competitor from importing what we export. We’re just a little hesitant in making our API the main conduit for that. So, if you want to have a valuable discussion on this at BloggerCon, I think you have to do it with all the nuances and complexities intact. Otherwise it just becomes empty rhetoric.

    (Also, less important, but still a correction: we never released the import tool from Buzznet to Flickr because it seemed like a cheap shot. We’re not changing any rules.)

  3. Dave Winer Says:

    Whoa, I didn’t ignore your email, I didn’t get it. Geez Louise, can we cut the invective down just a tad. Benefit of the doubt time. Dave

  4. Stewart Butterfield Says:

    Dave: Ok, no problem. Benefit of the doubt granted (in fact, if you say you didn’t get it, I believe you - no doubt required ;)

    I had assumed you received it and was annoyed that you didn’t respond, since I figured you’d understand exactly what I was saying in a way that most people wouldn’t, and because I saw the update on Scripting News today on a similar point but with no mention.

    Anyway, I hope you read the whole thing. There’s some context here that I think is important and I’m hoping that that gets carried into the general conversation about it. No invective. Peace.

  5. Marc’s Voice » Blog Archive » By Users, for Users, about Users who are used to being used Says:

    [...] As I susepcted Stewart Butterfield has a perfectly sound and logical stream of reason why they’re “not making it easy” for their direct competitor Zoomr to have access - via Flickr authentication - into ANY end-users record. [...]