Technology buzzwords come and go…virtualization, green, SaaS…and after sitting through the Google Friend Connect announcement, reading about Facebook’s Connect service and writing about last week’s MySpace Data Availability launch, “open” appears to be just the latest. But open is one of those words whose definition can be spun into a variety of meanings.

While Facebook isn’t yet releasing much detail on its efforts and may completely surprise me, Google’s Friend Connect program today highlights how open standards such as OpenID, OAuth and OpenSocial can be used to create a platform that’s pretty closed. The service, which will launch tonight and only expects to have between 12 and 24 sites participating while it’s in preview mode over the next few months, will allow site publishers to put some code on their sites. If a user visits a site with the appropriate code, she can get access, via an IFrame, to applications built in OpenSocial. A user can also share her activities on a participating site with her contacts, as well as through her news feeds on participating social networking sites.

Last week, I pointed out that MySpace’s Data Availability efforts were welcome in that they expand the number of sites on which a user can use her MySpace data, but that MySpace still had a lock on the user data since it hosted and determined who could display that data by approving site partners. If MySpace’s efforts were three steps forward in opening up user profiles, then Google’s Friend Connect represents two steps back.

The use of the IFrame means that site owners have no way to change or work with user data, they can only display it. MySpace doesn’t allow sites to store user data on anyone’s servers other than its own, but it does allow that data to be used directly in the outside site. For more differences among the three services, please check out the chart below.

While none of these services are entirely open yet — and may never be, given security and data abuse problems — the trend toward a more social web is clear. With broadband more prevalent than ever and voice fading as the primary means of communicating with people who aren’t in the room, enabling a truly open social web is the next big step in communication. But in order for that to happen, the user needs to be able to reach across walled gardens and gain granular control as to what he or she shares and with whom.

There’s open source (really open in that anyone with knowledge can participate in how the code evolves), open standards (open only in that anyone can participate using a pre-defined version of the standard), and open APIs (open in that anyone can take the pre-defined standard and build something for a closed platform such as Facebook). Knowing this, the efforts to open up a user’s data on a social network (their social graph, if you will) by these three companies falls somewhere between an open platform and an open standard.

New York-based cloud computing startup 10gen launched today with backing from CEO Kevin Ryan’s startup network, Alleycorp. It makes sense, since with several ventures already under his belt, Ryan probably has enough customers to both justify the buildout and break even right away. And the founders know scaling, having built out ad network DoubleClick.

But is it always a good idea to build your own cloud when you get big enough to do so?

Yesterday, for example, I had a great chat with Lana Holmes, a Bay area startup maven, about product management and how to focus on doing the one thing that matters to your company. “The example I use is Amazon,” she said. “They just focused on selling books. And look at them now.”

At their root, Amazon’s EC2 and S3 offerings are the result of excess capacity from sales. The offerings have paved the way for an online world in which compute power is a commodity. The company has subsequently built, on top of those offerings, a layer of billing, services and support for them.

The motivation behind the creation of 10gen is similar: If you successfully launch a number of web firms, at a certain point the economies of scale of others’ clouds starts fall away and you may as well run your own.

It’s easier than ever to launch your own cloud. You’ve got grid deployment tools from folks like 3Tera and Enomaly. Virtualization management can be had from the likes of Fortisphere, Cirba and ManageIQ, to name just a few. And license management (built into cluster deployment from companies like Elastra) is knocking down some of the final barriers to building a cloud that you can offer to third parties as well.

But imagine a world in which there are hundreds of clouds to choose from. Moving a virtual machine is supposed to be as easy as dragging and dropping, and cloud operators will hate that. They’ll resist, putting in proprietary APIs and function calls. Applications and data won’t be portable. You’ll be locked in to a cloud provider, who will then be free to charge for every service. Sound familiar?

My guess is that as the cloud computing market grows and matures, one (or more) of three things will happen:

• Standardization and portability, in which consortia of cloud vendors agree to a standard set of APIs and coding constraints that guarantee interoperability. This isn’t just about the virtual machines; they’re fairly standard already. It’s about the data storage systems and the control APIs that let cloud users manage their applications. This is the mobile phone model, where number portability is guaranteed and there are well-known services like voice mail and call forwarding.
• Shared grid computing, in which smaller clouds sell their excess capacity to bigger clouds. This would let the big cloud dominate while paying the smaller cloud just enough to stop it from launching an offering of its own. Think of this as the electric company model, selling computing between clouds the way a solar-powered household can pump excess electricity into the power grid.
• Specialization, where clouds are good at certain things. You’ll get OS-specific clouds (Heroku is already providing optimized Rails deployment atop EC2.) It’s only a matter of time before we see clouds tailored for specific industries or the services the offer — anything from media to microtransactions. Sort of like the cable channel model, with specialized programming that allows niche channels too survive.

Whatever happens, it’s clear that good old-fashioned branding, plus a healthy dose of experience, will be key to winning as a cloud provider.

During a panel at Interop last week that I sat on with folks from Amazon, Opsource, Napera, Syntenic and Kaazing, I asked the audience how many of them would entrust Microsoft to run a cloud with Microsoft applications, and how many would prefer to see Amazon running a Microsoft kernel on EC2. Roughly 75 percent said they’d trust Amazon to run Microsoft’s own apps rather than Microsoft.

So when’s the right time to launch a cloud computing offering of your own? Unless you have the branding and reputation to support that launch — or you can re-sell excess capacity to partners or specialize — maybe never.

If this story interests you then you should definitely check out our upcoming conference, Structure 08.

I have a major problem with many of the Web 2.0 companies that I meet in my job as a venture capitalist: They lack even the most basic understanding of Internet operations.

I realize that the Web 2.0 community generally views Internet operations and network engineering as router-hugging relics of the past century desperately clutching to their cryptic, SSH-enabled command line interfaces, but I have recently been reminded by some of my friends working on Web 2.0 applications that Internet operations can actually have a major impact on this century’s application performance and operating costs.

So all you agile programmers working on Ruby-on-Rails, Python and AJAX, pay attention: If you want more people to think your application loads faster than Google and do not want to pay more to those ancient phone companies providing your connectivity, learn about your host. It’s called the Internet.

As my first case in point, I was recently contacted by a friend working at a Web 2.0 company that just launched their application. They were getting pretty good traction and adoption, adding around a thousand unique users per day, but just as the buzz was starting to build, the distributed denial-of-service (DDOS) attack arrived. The DDOS attack was deliberate, malicious and completely crushed their site. This was not an extortion type of DDOS attack (where the attacker contacts the site and extorts money in exchange for not taking their site offline), it was an extraordinarily harmful site performance attack that rendered that site virtually unusable, taking a non-Google-esque time of about three minutes to load.

No one at my friend’s company had a clue as to how to stop the DDOS attack. The basics of securing the Web 2.0 application against security issues on the host system — the Internet — were completely lacking. With the help of some other friends, ones that combat DDOS attacks on a daily basis, we were able to configure the routers and firewalls at the company to turn off inbound ICMP echo requests, block inbound high port number UDP packets and enable SYN cookies. We also contacted the upstream ISP and enabled some IP address blocking. These steps, along with a few more tricks, were enough to thwart the DDOS attack until my friend’s company could find an Internet operations consultant to come on board and configure their systems with the latest DDOS prevention software and configurations.

Unfortunately, the poor site performance was not missed by the blogosphere. The application has suffered from a stream of bad publicity; it’s also missed a major window of opportunity for user adoption, which has sloped significantly downward since the DDOS attack and shows no sign of recovering. So if the previous paragraph read like alphabet soup to everyone at your Web 2.0 company, it’s high time you start looking for a router-hugger, or soon your site will be loading as slowly as AOL over a 19.2 Kbps modem.

Another friend of mine was helping to run Internet operations for a Web 2.0 company with a sizable amount of traffic — about half a gigabit per second. They were running this traffic over a single gigabit Ethernet link to an upstream ISP run by an ancient phone company providing them connectivity to their host, the Internet. As their traffic steadily increased, they consulted the ISP and ordered a second gigabit Ethernet connection.

Traffic increased steadily and almost linearly until it reached about 800 megabits per second, at which point it peaked, refusing to rise above a gigabit. The Web 2.0 company began to worry that either their application was limited in its performance or that users were suddenly using it differently.

On a hunch, my friend called me up and asked that I take a look at their Internet operations and configurations. Without going into a wealth of detail, the problem was that while my friend’s company had two routers, each with a gigabit Ethernet link to their ISP, the BGP routing configuration was done horribly wrong and resulted in all traffic using a single gigabit Ethernet link, never both at the same time. (For those interested, both gigabit Ethernet links went to the same upstream eBGP router at the ISP, which meant that the exact same AS-Path lengths, MEDs, and local preferences were being sent to my friend’s routers for all prefixes. So BGP picked the eBGP peer with the lowest IP address for all prefixes and traffic). Fortunately, a temporary solution was relatively easy (I configured each router to only take half of the prefixes from each upstream eBGP peer) and worked with the ISP to give my friend some real routing diversity.

The traffic to my friend’s Web 2.0 company is back on a linear climb – in fact it jumped to over a gigabit as soon as I was done configuring the routers. While the company has their redundancy and connectivity worked out, they did pay their ancient phone company ISP for over four months for a second link that was essentially worthless. I will leave that negotiation up to them, but I’m fairly sure the response from the ISP will be something like, “We installed the link and provided connectivity, sorry if you could not use it properly. Please go pound sand and thank you for your business.” Only by using some cryptic command line interface was I able to enable their Internet operations to scale with their application and get the company some value for the money they were spending on connectivity.

Web 2.0 companies need to get a better understanding of the host entity that runs their business, the Internet. If not, they need to need to find someone that does, preferably someone they bring in at inception. Failing to do so will inevitably cost these companies users, performance and money.

If this story interests you then you should definitely check out our upcoming conference, Structure 08.

You can all Xohm now — and call it Clearwire. The much talked about WiMAX joint venture between Clearwire and Sprint Nextel is going to happen and the news is going to come as soon as tomorrow. The combined company is going to be worth $12 billion, The Wall Street Journal reports. Here are some facts:

• Comcast is pumping in $1.05 billion.
• Intel Corp. is putting in $1 billion.
• $550 million will come from Time Warner Cable.
• $500 million will come from Google.
• $100 million will come from Bright House Networks.
• The new company is also going to be called Clearwire.
• Current Clearwire CEO Ben Wolff will also be the CEO of the new company, Craig McCaw will be chairman.
• The service will offer voice service and broadband.
• Cable providers will sell it under their own brand, with a re-seller agreement with the new Clearwire.
• There is a good chance this service comes out before the wireless guys roll out their LTE networks.

Other details are sketchy, but here are my thoughts:

• Sprint Xohm is dead.
• Craig McCaw can chalk this up another win — he saved his near-disaster investment(s) in Clearwire with this deal.
• Intel will throw mad money to save some of its investments, however foolish they might be.
• McCaw & Wolff bluffed their way to a sweetheart deal. The cable companies, Google and Sprint are all playing from a position of fear. McCaw made AT&T buy his wireless operation, spend billions on it and then walked away, smelling very green. Same is true this time.
• Many might see this as a win for Dan Hesse; I think of it as the start of one giant hack job in Overland Park, Kan. He will sell Nextel and be left with a puny Sprint that will eventually be sold to T-Mobile or someone willing to pay up just to shut up Wall Street.
• You might want to recall the AT&T implosion and the end of Michael Armstrong, who had the right ideas at the wrong time. Of course, he listened to Wall Street too much.
• The big winners will be the equipment providers: Motorola, Nortel, etc.

The elephant in the room:

This is a spaghetti-like mess of conflicts and self-interests. I wonder how open this network is going to be? Clearwire has a history of blocking other services such as VoIP carriers. Comcast is a known P2P offender. Will Google be our only search option?

The final word:

I told you so comes to mind :-)

The demand for broadband in the U.S., after growing at an explosive rate for almost two years, has started to slow, largely due to high market penetration rates and a struggling economy. UBS Research forecasts that the number of U.S. broadband connections will grow 11 percent in 2008, down from growth of 16 percent in 2007. The carriers — the cable operators and phone companies — are beginning to feel the impact, and are subsequently looking for ways to squeeze more dollars out of the broadband business.

Verizon, for example, is pushing people to sign up for its more expensive FiOS service. Others are looking to use “speed boosts” as a way to lift their ARPU. This is not a new strategy: BellSouth, before it was acquired by AT&T, made good money by selling higher-speed tiers at a premium.

The latest company to follow this path is Windstream, a Little Rock, Ark.-based RLEC. The company said recently that it’s offering 12 Mbps ADSL2 service in some parts of its 16-state network. More importantly, it has increased its lowest-speed tier to 3 Megabits per second. Our good friends at DSLReports add that Windstream is offering the 12Mbps/1Mbps tier for $19.99 for the first six months, and $45 per month after that.

In recent months, Comcast started experimenting with 50 Mbps service (in Minneapolis), while Qwest said it it will start offering two new, higher-tier services — Qwest Connect Quantum (20 Mbps) and Qwest Connect Titanium (12 Mbps) — in certain cities. Broadband providers will have to convince consumers that they need the speed boost, however — that speed can improve their online experience.

It should come as no surprise that the carriers have let go of incremental speed upgrades and have gone ahead and doubled or tripled the speeds of their offerings. Why? Because bumping speed to 2 Mbps from 1 Mbps doesn’t really feel like a big boost. A 6X speed bump, on the other hand, makes the Internet much faster — and worth paying for. Suddenly, Hulu and YouTube become much more fun to watch. If a subscriber believes that he or she can download music, stream videos and connect to their favorite social networks faster, they will pay a premium price for that speed.

Never mind the fact that how fast content gets delivered to our computers is mandated by not just access speeds but several factors, such as congestion on the backbone networks and servers’ ability to dish out data. As our accompanying chart shows, the downstream speeds might be going up, but the carriers are stifling innovation by controlling the upstream speeds.

Broadband 2.0 is all about collaboration and sharing, and that requires just as much upstream bandwidth as it does downstream speeds. Regardless, this coming year is going to be fun as the cable companies and phone operators will do unnatural things to entice new subscribers, starting with offering faster connections at lower prices. Nothing wrong with that.