The real hurdle for Google Buzz is going to be migrating the massive social graph that exists on Facebook.
The people with "automatic" access to Buzz (existing Gmail users) already have a massive existing social graph in the form of mail contact lists (which, if the user also has Voice, is also their Voice contact list, which may also be synced to their actual mobile phones contact list.)
The ability to search public Buzz posts, and the location-aware ability to view nearby public Buzz posts provide a discovery mechanism which doesn't rely on a pre-existing social graph (but which promotes further development of the social graph.)
The problem is that Gmail is a client for the open communication protocol known as e-mail. Many people use Gmail, but not everybody wants to. I doubt Yahoo mail, or AOL mail users are interested in dropping their mail service just to join Google's new social venture, or adding 'Buzz' to their list of things to check every day.
Buzz is an application that aggregates a number of existing services and which can be both fed and consumed via a number of open protocols.
Google had a better idea with Wave: produce an open protocol that anybody could host. If Google did this from the get-go with 'Buzz', it would have a fighting chance.
Google has gone one better with Buzz -- it uses a number of existing, and already in use, open protocols (Atom/RSS, PubSubHubbub, XFN, MediaRSS, etc.), rather than creating a new one. This seems to make it trivial to use existing tools to consume information from Buzz and to feed into Buzz.
You should definitely ask Facebook for your money back.
Or, better, if you aren't happy, stop giving them your eyeballs, which is the product they sell to their customers, who are their advertisers.
Just because a service is free of monetary charge doesn't mean you aren't giving the provider of the service something that is of value to them in order to use it.
The whole "its free, so you can't expect anything" argument is fundamentally flawed; things that are free of charge aren't free of cost (particularly, the opportunity cost of choosing to use it instead of doing something else), and a for-profit business that offers something "free" still is expecting to receive something of value to the business in exchange. If its not providing a value that justifies the opportunity cost, the business isn't going to keep getting the thing of value that it wants out of the deal. A business that takes users of a "free" service for granted while relying on them for the resource it is selling to its paying customers is in for a rude awakening when someone provides a superior competing service and steals the "free" users away.
CNET identifies a central obstacle Buzz will have to overcome to gain traction: "The problem, however, will be the increasing backlash Google is seeing from the general public over how much data the company already controls on their online habits."
While complaints of this type are frequent from privacy-oriented action groups, and Slashdot users, I haven't seen a whole lot of evidence that there is a whole lot of traction for this kind of anti-Google sentiment in the general public. I think sometimes tech journalists confuse the circle of other technical journalists they associated with and technical-user-focussed media that they consume with the "public".
It is boring:(. If everybody else on the internet has a slow connection, then you can hardly ever download/upload with more than 50Mbit.
If Google succeeds in rolling out gigabit internet connections in test markets and then expands beyond that, gigabit connections will rapidly become less boring, because more people will have gigabit connections.
Among many other reasons, its a net neutrality insurance policy. Google favors net neutrality, but if net neutrality foes succeed (and that's an ongoing threat, because they don't tend to back off even as the FCC reiterates its support for net neutrality principles) it needs its own links directly to consumers as a hedge against other big network providers (particularly those that are also trying to compete with other Google services, whether video offerings that compete with YouTube, phone offerings that compete in some ways with Voice, or something else) -- impairing access to Google's services. If Google can position themselves as a competitive fiber-to-consumer provider, it puts them in a position where such actions by competing service providers that are also fiber providers are riskier because of the potential for retaliation.
Google has a strategic investment in not making the internet into a set of disjoint walled gardens, but ultimately the best way of insuring that is to guarantee that if its competitors try to convert it into such a system, those competitors will lose.
Why isn't this kind of technology being used to fight botnets?
Probably because in many countries, remotely infecting and installing/removing software and other data on computers without authorization from the owner of the system is illegal.
Couldn't a program be released using virus-like means to disseminate itself, and try to eliminate malicious software wherever it finds it?
If you are making a tool to compromise system to build botnets, you probably don't care too much if it occasionally gets a false positive and trashes important software or data on the a target machine when trying to destroy competing malware, and any additional liability that destruction exposes you to is probably minor compared to the legal liability from the intended function of the software,.
If you are making "beneficial" software, the risk-reward assessment is different, and will weigh heavily in favor of not using viral distribution means, but getting people to voluntarily accept your software -- giving you the existing array of anti-malware software of various kinds.
I'd actually prefer that to Facebook, where you get fake-personalized ads for generic (often scammy) offers using your profile information constantly: "46-year old single male in the 1900 block of North Avenue in Springfield, AR? You can get car insurance for $0.26/aeon! Click here!"
Really, though, there needs to be a "feature" that is exciting for the young crowd.
Buzz has a couple of features that might qualify: 1. In addition to Twitter/FB-style "follow a list of people" view, it has a "view nearby" mode that uses your location, and location data included with posts (including location is optional) to view recent posts that are near your location. (And this feature links to Google Locations -- to provide named locations which can information associated with them besides just "Buzz" posted from them -- and to Google Maps.) 2. Vs. Facebook, but not Twitter -- which Buzz captures directly -- it may be an advantage that public Buzz posts are searched by Google's main search engine, and can be displayed in the scrolling "recent results for foo" box in any search they are returned for (at least, I'd assume that Buzz posts are captured, since the scrolling results box which includes both recently-posted traditional web results but also twitter posts appeared at the same time as Buzz, one of whose flagship features is that in addition to posts from Buzz it can follow posts from Twitter; I would assume that the twitter messages included in the search results now are from the same messaging feed that Google uses to integrate Twitter and Buzz notifications to send them to the Buzz UI.)
But, I think the big thing for it will be how Buzz is leveraged by third-party sites using the the supported APIs.
Give me wave as a social network, and I will be happy. Technically, people can already do this, but... a 'publish and let people follow if they wish' sort of approach is better than a defined list of recipients.
A defined list of recipients is essential if there are things you don't want to share with everyone, public posts that people can follow (either by searching for particular keywords, or following a particular poster) are good for other things. Buzz supports both.
You don't actually need much more than that, to make something that'll be better than most of the competition.
"Publish and let people follow if they wish" is the Twitter model. You need something significantly more than that to give people a reason to use Buzz rather than Twitter.
They're gaining access to data similar to what Facebook has, yes. If Google Social Networking and Mail becomes more popular than Facebook, then whatever Facebook has won't matter, because Google will have better social networking data than Facebook. Which is what we don't want.
By way of Google's existing social offerings, (Mail, Talk, Voice, Blogger, YouTube, etc., etc., etc.) Google probably already has better social graph data than Facebook, and more of it concerning things people might want to be "private".
I'm not sure why "we" don't want that. Presumably, if "we" are concerned about that kind of data being in the hands of a company, we just won't use any social networking service, to deny anyone that kind of data -- its quite possible to do social networking completely offline, and probably much better for things that you really want completely private.
I don't think I did, which is why I said your general point may be valid, but the example didn't demonstrate it.
Sometimes, there is NO compensation.
Congressman Joe Murtha may have died unnecessarily due to a surgical error. How do you compensate Joe?
Yes, the cases where people die would be better examples of cases where compensation isn't an adequate remedy (although, you'll notice, they are also the cases where we mostly handle them by holding people responsible; we may occasionally also take additional preventive measures in particular circumstances, but the main approach to addressing the problem that "people sometimes do things they shouldn't and cause other people to die" is "hold people accountable when they do that.") Sometimes accountability (compensation + punishment) isn't enough to correct the problem entirely, but is still the best available method of addressing the problem.
They have a clear vision with Wave? If they do, they have done a terrible job communicating it. Wave looks promising to us propeller heads, but the general public is confused by Wave.
I think the Wave application is basically just a proof-of-concept to draw interest from, as you say, "propeller heads". The clear vision with Wave isn't something that is clear through the application as such, but instead clear through the existence of the Wave Protocol and infrastructure and the conceptual documents surrounding it. Its a vision of the web evolving along the same general lines that many have advocated as the right direction for enterprise architecture -- a world of loosely coupled components interacting over an asynchronous messaging backbone and sharing data in common formats, rather than big monolithic applications.
I think GP is perceptive in seeing Buzz as an application of that vision (particularly if you look at its interactions with other Google services, like Maps.)
I really do not want a constant flow of inane jibberings from every person in my gmail contact list day after day.
Like Twitter, you can control who you are following on Buzz, so if you don't want to get your contacts Buzz updates, don't actively choose to follow them on Buzz.
Google will fail to get a foothold for one reason laziness, the masses will not want to change over their account to something else.
Lots of people already have Google Accounts, and already use them "socially" (via Mail, Talk, Calendar, Voice, Blogger, etc.) These services are already somewhat integrated (Talk is available in the Mail UI, Mail and Talk are both available for contacts through the Voice mobile UI, contacts are synchronized throughout the account, etc.) Buzz ads microblogging/status in a Twitter/Facebook like sense to the existing social features of Google Accounts (with out of the gates integration into Google's mobile search app, Maps, etc., but its not Google trying to get a foothold in the social media space. Its Google enhancing its features in that space to avoid losing ground.
I do not want them seeing each other, seeing when I am online, what I am doing, where I am, or anything of the sort!
Just because Buzz is available in Gmail doesn't mean Google is forcing you to use it if you use Gmail, or automatically posting status updates for you. If you don't choose to share information, its not shared. Not that hard.
I will not use this until I can play Farmville on it and send people were-pigs and pork-knights so they can defend themselves properly.
While I don't know of anything like Farmville on it yet, Google does have an publicly available application infrastructure with free and paid hosting, integration into Google Accounts, etc., available already.
There are some things that cannot be resolved by a 'hold them responsible for fuckups' policy. You would probable, for instance, not be impressed by that policy if it required firing several people who let your financial data spew forth. After all, your credit is gone, your house is gone, your future is unnecessarily complicated, and it will take years to put it all back. No amount of retribution will fix it or make you whole.
The general claim may be valid, but the example is clearly pretty bad -- a company whose actions caused you harm firing a few people but doing nothing to compensate you for the harm done isn't being held responsible for their failure, so the idea that such a policy would be inadequate does not demonstrate that the situation cannot be resolved by a "hold them responsible" policy, it just shows that the situation isn't adequately addressed by a scapegoating policy.
Now, if the company were civilly liable to you for compensatory damages covering all of the harm you bear as a result of an unauthorized release of your data regardless of what steps they took in protecting it, and additionally liable for punitive damages and/or their management was subject to criminal sanction if the failure involved deliberate misconduct or failure to implement specified minimal safeguards, you'd be more likely to be satisfied with the policy.
Of course, the companies subject to it would be less likely to be satisfied and would lobby against such a policy.
We've read many reports of data breaches, and the result is not mitigated by punishing those responsible.
If those responsible were really held accountable, which they generally are not effectively, then we'd read a lot fewer reports of data breaches. Most existing policies are designed to provide shelter against responsibility for breaches -- they tend say as long as you provide safeguard A and, if it fails and a breach occurs, follow notification procedure B, you are not liable for the resulting harms.
The drawback for the Wii is that (at least with people I know) we don't have people over every day...so most people's Wii's are gather dust until they have a party every few months whereas people are always playing their 360.
Most people I know fit one or more of the following categories: (1) Married, (2) Have children, (3) Have roomates.
So, local multiplayer isn't really restricted to "when guests are over". Also, everyone I know that has one or more current-gen consoles has a Wii (though they may also have a Xbox 360 or PS3 -- I personally have a Wii and a PS3.)
Also, the 360 tends to attract people who buy more games. Where the Wii hit a whole new market of people who buy maybe a game or two a year.
Since the 360 (and the PS3) are sold under business models that rely on people buying lots of games to make them viable, while the Wii is (from everything I've heard) more profitable on its own than the other current consoles, this reflects, to a certain extent, each console being marketed to the place it needs to be to make money.
Quite frankly, the Wii was very smart for staying in the price range it did, but it needs to have a shorter life cycle because there are many games that skip over the Wii because it can't handle the graphics or the amount of AI require to play a game. [...] Combine that with the weak attach rate third party games get with the Wii and it just isn't that compelling of a platform for anyone but Nintendo and people who want to make party games.
As long as it is compelling for Nintendo, why does it need to have a shorter life cycle? AFAICT, the difference here is one of business models: Wii makes money for Nintendo on the hardware, and on first party games. Charges to third party developers are secondary (though they do make Nintendo some additional money.) OTOH, Sony and Microsoft consoles are sold under a business models where making money through fees charged to third-party developers are more central. So, they need to be attractive platforms for third-party developers to be viable.
While it may not be your preference, applications written in Ruby are supposed to be written in such a way that they are self documenting.
Code in any language should be self-documenting to the extent the language allows, that doesn't excuse not doing additional documentation when the language (or your use of it) isn't sufficiently self-documenting. Rdoc -- which is included with Ruby -- generates documentation by reading the code and comments for a reason -- because it is assumed that code will not always be sufficient documentation on its own.
Contrary to other languages, the expressiveness of Ruby allows the developer to write code that means as much, if not more, than formal documentation.
Compared to static languages live Java, its very hard to explicitly express things like expectations about arguments clearly in code in Ruby, and the kind of tests that would express these expectations more clearly are often considered bad style, except in very particular circumstnaces. Documenting these expectations in comments which turn into API docs via Rdoc would seem to generally be the right thing to do.
Nevertheless, while you can both create a new record with an ID, or specify your own ID for an object, the former can cause issues if you are not careful, and the latter was determined by the Rails folks (correctly) to be generally BAD PRACTICE, because any logic errors on your part could hopelessly (and very easily) screw up your DB's table index.
It could cause the insert to fail, but unless you have a database that can't properly enforce uniqueness constraints (which would be a phenomenally bad database) you can't actually screw up the index. You might (with certain systems of automatically generating default IDs) cause future inserts using the default index value to fail unexpectedly, but the actual table index would be fine.
Slashdot Mirror
The people with "automatic" access to Buzz (existing Gmail users) already have a massive existing social graph in the form of mail contact lists (which, if the user also has Voice, is also their Voice contact list, which may also be synced to their actual mobile phones contact list.)
The ability to search public Buzz posts, and the location-aware ability to view nearby public Buzz posts provide a discovery mechanism which doesn't rely on a pre-existing social graph (but which promotes further development of the social graph.)
Buzz is an application that aggregates a number of existing services and which can be both fed and consumed via a number of open protocols.
Google has gone one better with Buzz -- it uses a number of existing, and already in use, open protocols (Atom/RSS, PubSubHubbub, XFN, MediaRSS, etc.), rather than creating a new one. This seems to make it trivial to use existing tools to consume information from Buzz and to feed into Buzz.
Or, better, if you aren't happy, stop giving them your eyeballs, which is the product they sell to their customers, who are their advertisers.
Just because a service is free of monetary charge doesn't mean you aren't giving the provider of the service something that is of value to them in order to use it.
The whole "its free, so you can't expect anything" argument is fundamentally flawed; things that are free of charge aren't free of cost (particularly, the opportunity cost of choosing to use it instead of doing something else), and a for-profit business that offers something "free" still is expecting to receive something of value to the business in exchange. If its not providing a value that justifies the opportunity cost, the business isn't going to keep getting the thing of value that it wants out of the deal. A business that takes users of a "free" service for granted while relying on them for the resource it is selling to its paying customers is in for a rude awakening when someone provides a superior competing service and steals the "free" users away.
While complaints of this type are frequent from privacy-oriented action groups, and Slashdot users, I haven't seen a whole lot of evidence that there is a whole lot of traction for this kind of anti-Google sentiment in the general public. I think sometimes tech journalists confuse the circle of other technical journalists they associated with and technical-user-focussed media that they consume with the "public".
If Google succeeds in rolling out gigabit internet connections in test markets and then expands beyond that, gigabit connections will rapidly become less boring, because more people will have gigabit connections.
Among many other reasons, its a net neutrality insurance policy. Google favors net neutrality, but if net neutrality foes succeed (and that's an ongoing threat, because they don't tend to back off even as the FCC reiterates its support for net neutrality principles) it needs its own links directly to consumers as a hedge against other big network providers (particularly those that are also trying to compete with other Google services, whether video offerings that compete with YouTube, phone offerings that compete in some ways with Voice, or something else) -- impairing access to Google's services. If Google can position themselves as a competitive fiber-to-consumer provider, it puts them in a position where such actions by competing service providers that are also fiber providers are riskier because of the potential for retaliation.
Google has a strategic investment in not making the internet into a set of disjoint walled gardens, but ultimately the best way of insuring that is to guarantee that if its competitors try to convert it into such a system, those competitors will lose.
Probably because in many countries, remotely infecting and installing/removing software and other data on computers without authorization from the owner of the system is illegal.
If you are making a tool to compromise system to build botnets, you probably don't care too much if it occasionally gets a false positive and trashes important software or data on the a target machine when trying to destroy competing malware, and any additional liability that destruction exposes you to is probably minor compared to the legal liability from the intended function of the software,.
If you are making "beneficial" software, the risk-reward assessment is different, and will weigh heavily in favor of not using viral distribution means, but getting people to voluntarily accept your software -- giving you the existing array of anti-malware software of various kinds.
I'd actually prefer that to Facebook, where you get fake-personalized ads for generic (often scammy) offers using your profile information constantly: "46-year old single male in the 1900 block of North Avenue in Springfield, AR? You can get car insurance for $0.26/aeon! Click here!"
Buzz has a couple of features that might qualify:
1. In addition to Twitter/FB-style "follow a list of people" view, it has a "view nearby" mode that uses your location, and location data included with posts (including location is optional) to view recent posts that are near your location. (And this feature links to Google Locations -- to provide named locations which can information associated with them besides just "Buzz" posted from them -- and to Google Maps.)
2. Vs. Facebook, but not Twitter -- which Buzz captures directly -- it may be an advantage that public Buzz posts are searched by Google's main search engine, and can be displayed in the scrolling "recent results for foo" box in any search they are returned for (at least, I'd assume that Buzz posts are captured, since the scrolling results box which includes both recently-posted traditional web results but also twitter posts appeared at the same time as Buzz, one of whose flagship features is that in addition to posts from Buzz it can follow posts from Twitter; I would assume that the twitter messages included in the search results now are from the same messaging feed that Google uses to integrate Twitter and Buzz notifications to send them to the Buzz UI.)
But, I think the big thing for it will be how Buzz is leveraged by third-party sites using the the supported APIs.
A defined list of recipients is essential if there are things you don't want to share with everyone, public posts that people can follow (either by searching for particular keywords, or following a particular poster) are good for other things. Buzz supports both.
"Publish and let people follow if they wish" is the Twitter model. You need something significantly more than that to give people a reason to use Buzz rather than Twitter.
Because Google isn't trying to keep your data walled up so that you can't access it except through their site, while Facebook is.
By way of Google's existing social offerings, (Mail, Talk, Voice, Blogger, YouTube, etc., etc., etc.) Google probably already has better social graph data than Facebook, and more of it concerning things people might want to be "private".
I'm not sure why "we" don't want that. Presumably, if "we" are concerned about that kind of data being in the hands of a company, we just won't use any social networking service, to deny anyone that kind of data -- its quite possible to do social networking completely offline, and probably much better for things that you really want completely private.
I don't think I did, which is why I said your general point may be valid, but the example didn't demonstrate it.
Yes, the cases where people die would be better examples of cases where compensation isn't an adequate remedy (although, you'll notice, they are also the cases where we mostly handle them by holding people responsible; we may occasionally also take additional preventive measures in particular circumstances, but the main approach to addressing the problem that "people sometimes do things they shouldn't and cause other people to die" is "hold people accountable when they do that.") Sometimes accountability (compensation + punishment) isn't enough to correct the problem entirely, but is still the best available method of addressing the problem.
I think the Wave application is basically just a proof-of-concept to draw interest from, as you say, "propeller heads". The clear vision with Wave isn't something that is clear through the application as such, but instead clear through the existence of the Wave Protocol and infrastructure and the conceptual documents surrounding it. Its a vision of the web evolving along the same general lines that many have advocated as the right direction for enterprise architecture -- a world of loosely coupled components interacting over an asynchronous messaging backbone and sharing data in common formats, rather than big monolithic applications.
I think GP is perceptive in seeing Buzz as an application of that vision (particularly if you look at its interactions with other Google services, like Maps.)
Like Twitter, you can control who you are following on Buzz, so if you don't want to get your contacts Buzz updates, don't actively choose to follow them on Buzz.
Lots of people already have Google Accounts, and already use them "socially" (via Mail, Talk, Calendar, Voice, Blogger, etc.) These services are already somewhat integrated (Talk is available in the Mail UI, Mail and Talk are both available for contacts through the Voice mobile UI, contacts are synchronized throughout the account, etc.) Buzz ads microblogging/status in a Twitter/Facebook like sense to the existing social features of Google Accounts (with out of the gates integration into Google's mobile search app, Maps, etc., but its not Google trying to get a foothold in the social media space. Its Google enhancing its features in that space to avoid losing ground.
Just because Buzz is available in Gmail doesn't mean Google is forcing you to use it if you use Gmail, or automatically posting status updates for you. If you don't choose to share information, its not shared. Not that hard.
Google is always working on integrating their projects. It doesn't make sense for them to stop all new projects to do this.
While I don't know of anything like Farmville on it yet, Google does have an publicly available application infrastructure with free and paid hosting, integration into Google Accounts, etc., available already.
The general claim may be valid, but the example is clearly pretty bad -- a company whose actions caused you harm firing a few people but doing nothing to compensate you for the harm done isn't being held responsible for their failure, so the idea that such a policy would be inadequate does not demonstrate that the situation cannot be resolved by a "hold them responsible" policy, it just shows that the situation isn't adequately addressed by a scapegoating policy.
Now, if the company were civilly liable to you for compensatory damages covering all of the harm you bear as a result of an unauthorized release of your data regardless of what steps they took in protecting it, and additionally liable for punitive damages and/or their management was subject to criminal sanction if the failure involved deliberate misconduct or failure to implement specified minimal safeguards, you'd be more likely to be satisfied with the policy.
Of course, the companies subject to it would be less likely to be satisfied and would lobby against such a policy.
If those responsible were really held accountable, which they generally are not effectively, then we'd read a lot fewer reports of data breaches. Most existing policies are designed to provide shelter against responsibility for breaches -- they tend say as long as you provide safeguard A and, if it fails and a breach occurs, follow notification procedure B, you are not liable for the resulting harms.
At most we have a bit of accountability theater.
Most workplaces I know that block webmail also block social networking sites, IME.
IME, most people that do that either work someplace that doesn't block webmail, or use their own mobile device rather than work computers.
Most people I know fit one or more of the following categories:
(1) Married,
(2) Have children,
(3) Have roomates.
So, local multiplayer isn't really restricted to "when guests are over". Also, everyone I know that has one or more current-gen consoles has a Wii (though they may also have a Xbox 360 or PS3 -- I personally have a Wii and a PS3.)
Since the 360 (and the PS3) are sold under business models that rely on people buying lots of games to make them viable, while the Wii is (from everything I've heard) more profitable on its own than the other current consoles, this reflects, to a certain extent, each console being marketed to the place it needs to be to make money.
As long as it is compelling for Nintendo, why does it need to have a shorter life cycle? AFAICT, the difference here is one of business models: Wii makes money for Nintendo on the hardware, and on first party games. Charges to third party developers are secondary (though they do make Nintendo some additional money.) OTOH, Sony and Microsoft consoles are sold under a business models where making money through fees charged to third-party developers are more central. So, they need to be attractive platforms for third-party developers to be viable.
Code in any language should be self-documenting to the extent the language allows, that doesn't excuse not doing additional documentation when the language (or your use of it) isn't sufficiently self-documenting. Rdoc -- which is included with Ruby -- generates documentation by reading the code and comments for a reason -- because it is assumed that code will not always be sufficient documentation on its own.
Compared to static languages live Java, its very hard to explicitly express things like expectations about arguments clearly in code in Ruby, and the kind of tests that would express these expectations more clearly are often considered bad style, except in very particular circumstnaces. Documenting these expectations in comments which turn into API docs via Rdoc would seem to generally be the right thing to do.
It could cause the insert to fail, but unless you have a database that can't properly enforce uniqueness constraints (which would be a phenomenally bad database) you can't actually screw up the index. You might (with certain systems of automatically generating default IDs) cause future inserts using the default index value to fail unexpectedly, but the actual table index would be fine.