Mar 8
▼Fact check thread.
Time to wrap up a number of outstanding threads and put the answers all in one place. I'll try to keep this updated as more strange or inaccurate things are posted. Please point the pundits over here if they seem confused.
Fact: Google has an, if not the, industry leading patent license for its data APIs.
From http://code.google.com/apis/gdata/patent-license.html :
"Subject to the terms and conditions of this License, Google hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this License) patent license for patents necessarily infringed by implementation (in whole or in part) of this specification. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the implementation of the specification constitutes direct or contributory patent infringement, then any patent licenses for the specification granted to You under this License shall terminate as of the date such litigation is filed."
There isn't a more permissive one in the industry. If you find one, let me know. I hate that stuff as much as you do.
Fact: Google can't just copy someone else's API without their permission.
Just like you can't copy someone's book, copy someone's music, or copy someone's invention without their permission, protocols and formats too need to be licensed for others to borrow and modify. This is why we have copyright licenses like the Creative Commons, and patent licenses like the one above or the Open Web Foundation Agreement. Google can't be the one who decides how someone else licenses their protocol. They need to adopt a license themselves if they want to encourage other people to clone their API.
(As a footnote, I spend a lot of my personal time working on open specification licensing. If your company is interested, I'm always available to sit down and help, because I think that web protocols should be freely available for others to use and modify.)
Fact: Google Buzz already supports RSS. And does it well.
And RDF, too. Feeds can be connected to Buzz using RSS, Atom, RDF, or any number of different formats and protocols. The feed parsing code behind Buzz is the same one used by Google Reader, which supports just about everything under the sun. (I know, I've personally checked in changes there to support things like Media RSS even better.) If you find something that doesn't work, it may be a bug on our end, so please file a ticket at http://code.google.com/p/google-buzz-api/issues so I can take a look.
Fact: PubSubHubbub supports RSS.
Not much more to say than that. If someone says otherwise, please tell them to try it first.
And the next version of the spec is going to support arbitrary media types, which will make not just feeds arrive instantaneously, but potentially any page or piece of content on the web. This is huge.
Fact: Google Buzz doesn't support rssCloud.
Yeah, that one is true. Probably won't any time soon, either. It's a combination of the spec simply not working at scale (the thundering herd problem), and not well at all behind NATs or firewalls (the ip callback provision), and that the messages lack a mechanism for verifiable provenance (a security, spam, and denial of service issue). Also, to be honest, the spec just needs a lot of work to be viable, but there aren't a large number of publishers using it. If things change down the road then we can revisit.
In the meantime, people are using the PubSubHubbub protocol, which doesn't have the same technical limitations, and is already available under a permissive patent and copyright license.
Fact: Google Buzz is built entirely around community authored protocols.
And the list of those protocols is almost absurdly long. I went through the other day and tried to list them all and highlight the people behind those protocols. You can read that list here:
- http://www.google.com/buzz/dclinton/D3bmGRHmyNb/
The most important ones, like Activity Streams, were even developed by some of Google's fiercest competitors. How's that for not reinventing the wheel?
And for the new protocols like Salmon, all of the work is being done on public mailing lists. We don't even use internal mailing lists for anything other than our internal implementation details when talking about those protocols. The idea is to do all the work in public.
Fact: Google doesn't "own the web".
This was an amusing one to me, partly because I'm not even sure what it means. Google is a search engine, and we crawl the public web just the same as everyone else. There are several popular competing search engines that keep us up working late into the night, and I don't doubt that if we ever slowed down even a little bit we'd be overtaken in a heartbeat.
Fact: What's good for the web is good for Google.
I wholeheartedly agree with this. When the web is healthy and the web grows, both in terms of number of users and amount of content for Google to index, then there are more people who might search the web on Google, and more things they might find, and that's certainly a good thing for us.
It's also great for an open web guy like me, because it means that I'm able to do what I do out in the open and with great sincerity (earnestness, really), and my work is aligned with the interests of the people writing my paycheck. I wouldn't have it any other way.
...
I'll try and keep this thread updated over time. Please add your questions and comments below.
Time to wrap up a number of outstanding threads and put the answers all in one place. I'll try to keep this updated as more strange or inaccurate things are posted. Please point the pundits over here if they seem confused.
Fact: Google has an, if not the, industry leading patent license for its data APIs.
From http://code.google.c
"Subje
There isn't a more permissive one in the industry. If you find one, let me know. I hate that stuff as much as you do.
Fact: Google can't just copy someone else's API without their permission.
Just like you can't copy someone's book, copy someone's music, or copy someone's invention without their permission, protocols and formats too need to be licensed for others to borrow and modify. This is why we have copyright licenses like the Creative Commons, and patent licenses like the one above or the Open Web Foundation Agreement. Google can't be the one who decides how someone else licenses their protocol. They need to adopt a license themselves if they want to encourage other people to clone their API.
(As a footnote, I spend a lot of my personal time working on open specification licensing. If your company is interested, I'm always available to sit down and help, because I think that web protocols should be freely available for others to use and modify.)
Fact: Google Buzz already supports RSS. And does it well.
And RDF, too. Feeds can be connected to Buzz using RSS, Atom, RDF, or any number of different formats and protocols. The feed parsing code behind Buzz is the same one used by Google Reader, which supports just about everything under the sun. (I know, I've personally checked in changes there to support things like Media RSS even better.) If you find something that doesn't work, it may be a bug on our end, so please file a ticket at http://code.google.c
Fact: PubSubHubbub supports RSS.
Not much more to say than that. If someone says otherwise, please tell them to try it first.
And the next version of the spec is going to support arbitrary media types, which will make not just feeds arrive instantaneously, but potentially any page or piece of content on the web. This is huge.
Fact: Google Buzz doesn't support rssCloud.
Yeah, that one is true. Probably won't any time soon, either. It's a combination of the spec simply not working at scale (the thundering herd problem), and not well at all behind NATs or firewalls (the ip callback provision), and that the messages lack a mechanism for verifiable provenance (a security, spam, and denial of service issue). Also, to be honest, the spec just needs a lot of work to be viable, but there aren't a large number of publishers using it. If things change down the road then we can revisit.
In the meantime, people are using the PubSubHubbub protocol, which doesn't have the same technical limitations, and is already available under a permissive patent and copyright license.
Fact: Google Buzz is built entirely around community authored protocols.
And the list of those protocols is almost absurdly long. I went through the other day and tried to list them all and highlight the people behind those protocols. You can read that list here:
- http://www.google.co
The most important ones, like Activity Streams, were even developed by some of Google's fiercest competitors. How's that for not reinventing the wheel?
And for the new protocols like Salmon, all of the work is being done on public mailing lists. We don't even use internal mailing lists for anything other than our internal implementation details when talking about those protocols. The idea is to do all the work in public.
Fact: Google doesn't "own the web".
This was an amusing one to me, partly because I'm not even sure what it means. Google is a search engine, and we crawl the public web just the same as everyone else. There are several popular competing search engines that keep us up working late into the night, and I don't doubt that if we ever slowed down even a little bit we'd be overtaken in a heartbeat.
Fact: What's good for the web is good for Google.
I wholeheartedly agree with this. When the web is healthy and the web grows, both in terms of number of users and amount of content for Google to index, then there are more people who might search the web on Google, and more things they might find, and that's certainly a good thing for us.
It's also great for an open web guy like me, because it means that I'm able to do what I do out in the open and with great sincerity (earnestness, really), and my work is aligned with the interests of the people writing my paycheck. I wouldn't have it any other way.
...
I'll try and keep this thread updated over time. Please add your questions and comments below.
102 people liked this - Adewale Oshineye, Andy C, Anup Jadhav, Ashton Lafferty, Atul Arora and 97 others, Audrea Huff, Ben Petro, Brett Cannon, Brian Stoler, Brian Sullivan, Brome Brome, Carsten Pötter, Chris Brierley, Chris Duffy, Chris Kim A, Chris Loft, Christian Martel, Chuck Falzone, Chung Wu, Claude LaFrenière, Colin Wernham, Daniel Sims, Daniele Gobbetti, David Glazer, Devanshu Mehta, Dominik Mayer, Ed Summers, Erica Baker, Gord McLeod, Gregory Smith, Ian McGee, J Michel Metz, J. McConnell, Jack Hebert, James Robinson, Jeff Johnson, Jeffrey Canton, Jim Ancona, Joe Beda, John Mueller, John Munro, John Panzer, Josh Mize, Josh Wills, Judson Dunn, Kathi [d/b/a fuzzyscorpio], Kazutaka Ogaki, Kevin C., Kevin Marks, Kevin Shea, Kevin Whalen, Kol Tregaskes, Kurt Starnes, Kyle Mathews, Laura Norvig, Linda Lawrey, Logical Extremes, Louis Gray, Luis Rodriguez, Mark Essel, Mark Trapp, Matt Mastracci, Miguel Eduardo Gil Biraud, Mihai Parparita, Mike Cohen, Mike Riversdale, Mike Taylor, Moishe Lettvin, Nyan Min, Patrick Aljord, Patrick Jones, Paul Chambers, Pereira Braga, Peter Hoffmann, Peter Keane, Peter Stuifzand, Piaw Na, Pierre Phaneuf, Rashon Ramsey, Rick Klau, Robert Birming, Robert Hancock, Robert Konigsberg, Robin Millette, Rory Parle, Sam Sethi, Satish Viswanath, Shakeel Mahate, Siegfried Hirsch, Slim Amamou, Stephen Allen, Susan Beebe, Thomas Hawk, Thomas Hoffbauer, Thomas Kjær Nielsen, Todd Jackson, Tyler Strause, Vlado Handziski, William Merriam, William St.Pierre, adam sah and mark mason
DeWitt Clinton - Please let me know if you think I left anything out. Happy to add more.Mar 8DeleteUndo deleteReport spamNot spam
Chris Myles - Fact: Google could easily launch a completely proprietary custom Buzz solution faster and easier than using open APIs.
Fact: Although "open" facebook and twitter APIs specifically cover their current toolsets, Open APIs developed in the open for the benefit of the community generally do a much better job providing enough flexibility for the future.Mar 8DeleteUndo deleteReport spamNot spam
Fact: Although "open" facebook and twitter APIs specifically cover their current toolsets, Open APIs developed in the open for the benefit of the community generally do a much better job providing enough flexibility for the future.Mar 8DeleteUndo deleteReport spamNot spam
Mark Essel - The DeWitt Clinton FAQ. Sweet :)
just started to get a handle on some of the open standards/protocols from Tyler Gillies. Looking forward to processing buzz/identi.ca/other
just started to get a handle on some of the open standards/protocols from Tyler Gillies. Looking forward to processing buzz/identi.ca/other
Mike Taylor - Mark: it's not the DeWitt Clinton FAQ sheet at all, IMO it's the Open Web at Google Fact Sheet.
heck, I would go so far as to say it's the Open Web Manifesto (draft)Mar 8DeleteUndo deleteReport spamNot spam
heck, I would go so far as to say it's the Open Web Manifesto (draft)Mar 8DeleteUndo deleteReport spamNot spam
DeWitt Clinton - Whoops, fixed a typo and a spelling error. Feel free to let me know about those, too.Mar 8DeleteUndo deleteReport spamNot spam
Matt Mastracci - Great FAQ, thanks for putting it together, Dewitt. The FUD that's slung against Buzz is starting to get tiresome. Having a highly visible open system like Buzz is big for the web and great for smaller players who want to easily plug into the 'net at large.
Myself and our whole team are very happy with the open state of Buzz from day one. It's a rough API and evolving rapidly, but better early than perfect. It's got a stellar future ahead of it.Mar 8DeleteUndo deleteReport spamNot spam
Myself and our whole team are very happy with the open state of Buzz from day one. It's a rough API and evolving rapidly, but better early than perfect. It's got a stellar future ahead of it.Mar 8DeleteUndo deleteReport spamNot spam
Louis Gray - Keep feeding us great content, DeWitt. Thanks.Mar 8DeleteUndo deleteReport spamNot spam
Douglas Landauer - It's a cool name because it showed up in a NYT crossword puzzle that I did just under two weeks ago: [Edited to point to the public rebuzz ...
http://www.google.com/buzz/109937363154511097852/K8ofyzXZ6gP/Early-New-York-governer-Rebuzz-3-8-original-was ].Mar 8DeleteUndo deleteReport spamNot spam
http://www.google
Derek Pangallo - I don't think you're going to get much recurring traffic if you update this. I love the idea of Buzz posts being less disposable, but I don't see anyone else using it this way. A few are starting to see the value of it as a blog, but we've a ways to go before it has the Wave dynamic. Does a Buzz bump to the top when it's edited (whether I interacted with it or not)?Mar 8DeleteUndo deleteReport spamNot spam
Linda Lawrey - ooooo.. ooooo !! Can I mention one with an answer? (the comment will get lost here but I'll post it anyway.
*"Google has no support forum"*
YES it does and anyone willing to assist in the forum is most welcome! Feed the questions to GReader and easily find the ones you can answer (or just peek in every now and then) and it only takes a moment. Experienced "power users" or just someone who knows a simple "how to" answer - all assistance is welcome. Especially for the new service BUZZ!
Use the Support Forum yourself when you have an issue.
http://www.google.com/support/forum?hl=en (All services - Note that Buzz at this time falls under Gmail but needs to be separated)
http://www.google.com/support/forum/p/gmail/label?lid=3a63236689cf8dbd&hl=en (Buzz)Mar 9DeleteUndo deleteReport spamNot spam
*"Google has no support forum"*
YES it does and anyone willing to assist in the forum is most welcome! Feed the questions to GReader and easily find the ones you can answer (or just peek in every now and then) and it only takes a moment. Experienced "power users" or just someone who knows a simple "how to" answer - all assistance is welcome. Especially for the new service BUZZ!
Use the Support Forum yourself when you have an issue.
http://www.goo
http://www
DeWitt Clinton has disabled comments on this post
Comment
Like