OpenSocial inching closer... but to what?

On January 25, Google released the 0.7 version of OpenSocial, detailed in the Release Notes published on their site. It is interesting what they prioritized enhancing in this version.

There is a drastically enhanced Person object. Excellent (I love people). This is described in the Release Notes as Standardized profile information fields, which makes sense, so multiple applications can leverage the same data. Or at least that's what I thought until I saw the fields available, which include:

Body Type

Fashion

Heroes

Scared Of

Turn Ons

You get the idea. Each of these has a specific structure, such as a comma-delimited string, or in the case of Smoker an ENUM including the VALUES "socially" and "regularly." I wonder if anyone would want to target ads to smokers. Oh wait... they actually only added 3 specific ENUMs (which I would have added when I really care about accuracy of the data), which are DRINKER, SMOKER, and GENDER. From an ad-centric perspective, each of those ENUMs smell like money.

Now if I were adding applications into this fabric, I'd want to attach my own data structures that other applications could leverage off of the profile. For example, I think that iLike has a much better idea of the appropriate structure for music preferences than OpenSocial. How about letting applications defined sections within the user profile? Ever hear of metadata? Maybe custom properties?

Ironically, in the Enterprise, the social fabric has to be more open. Yes, it has to be more secure, since data can be sacrosanct, but the Sales Regions I Care About in a CRM system will have a structure that the CRM system needs to articulate, not some master system deciding it needs to be in a comma-delimited-format, or as an ENUM including Idaho.

We are excited about OpenSocial, but ask the same thing of it that others are: please be Open. Let applications define their own data shapes on the social graph. Allow more interesting sets of people emerge than "Friends." This is important for it to be relevant in our increasingly social, increasingly modern workplaces.

As we map these concepts to the enterprise, we will be doing just that. And we are very excited about the possibilities, as are our customers...

OpenSocial and the Enterprise

Okay, we've heard a lot about Google's OpenSocial APIs, and clearly opinions vary, from unbridled excitement to downright skepticism from Tim O'Reilly, at least regarding what is available right now. But most of the commentary on the web has to do with the consumer space (not surprising), so what does this mean for the enterprise?

Let's start with what OpenSocial is today: it is a way for developers to write a social app (or micro-app) that plugs into any social "container" that supports the API, much like you would write a proprietary Facebook app to plug into Facebook. For people that have been involved in portals, it is analogous to the standard portlet APIs, such as WSRP or JSR-168, which let you write a portlet that works in any portal. Wow, that's exciting.

Well, it could be, but it isn't now, except for developers or startups trying to get presence in the consumer cloud. As Tim O'Reilly notes, it doesn't help the end user.

Most modern individuals have fragments of themselves in several social networks. We need a sort of broker that can figure out which applications can have access to which fragments in which networks. This way we don't need to repeat our information again and again but the value of the networks we join can be preserved effectively, and help the knowledge worker in the enterprise.

We've talked about AquaLogic Pathways, and how it maintains an activity graph of interactions in systems, both explicit and implicit. This graph helps people find people as well as information. This implicit social network could certainly benefit from networks in the cloud -- if you and I work together but are also friends on Facebook, our connection is also stronger in the enterprise, and our coworkers should be able to find me through you and you through me.

But now we're talking about the enterprise, where the rules are different. Some information is sensitive, some relationships are only for certain people to know about. Who "shares" what with whom can be complex. And almost none of this, for now, will be shared with the networks in the cloud.

So here is what we need: give us a data and social bridge from the cloud to the enterprise, so users can self-select what to "share" inwards. Enterprise systems can leverage the information it deems reliable (as discussed by Mark Cuban), which can make the enterprise more fun and more effective. This bridge will have to address basic things like identity mapping, and let users connect their various consumer systems for general, unified access by either cloud applications or enterprise applications. Let the enterprise pull data in today, and at some point it will be comfortable to push data out.

APIs can be a nice start, but design them for the use cases that empower the participant. I decide what I share on Facebook (even though I can't figure out how to hide all of those annoying zombies) and that is why Facebook is powerful and popular. Build me a bridge between systems, and I'll probably cross it. If the bridge goes to the enterprise, some of the energy and playfulness will come along as well.

They're all good, Bill

Bill Roth just provocatively posted that maybe all tags aren't good. I came up with a brilliant response:

They're all good, Bill. Really, they are.

The main problem with the alternative, is, well, the alternative. The alternative to the "false positive" problem is the idea that there are good descriptors and bad descriptors. There just aren't.

Let's describe Bill. Maybe developer tools, eclipse, BEA, blogger, these would all be good tags. But what about stagehand, actor, marquette tribune, bucky badger? It would depend on who you're talking with. If you're talking to Bill's college buddies, maybe the latter tags would be a much easier way to find him.

If one person tags an object, it is a good way for that same person to find it again, and that is enough. To thrive in the enterprise, you need to leverage people's selfish tendencies -- give them a way to get their job done easier. Whatever tags they use for that occasion, someone, even if it is only them, will benefit.

Of course the real enterprise needs some precautions, such as tagging blacklists, reserved words, etc., and Pathways can do all of that.

But then what about all of that noise? Won't it make the "real" tags disappear? Nope. Once there are a bunch of tags in the system, if people view the top 50 or top 100 in their tag cloud, they will only see the often-used tags, and the important (judged by ActivityRank) tags. The only times the "long tail" tags will show up if the search is so targeted that they rise to the top. And I can always use Views to see how a specific set of people have tagged it. If I am interested in Developer Tools, I might want to see the world with Bill Roth's view. Or maybe my son's. He's only two and a half, but that new generation seems to have something to say, even if I don't always understand him. His friends do, and those tags might help him show them the way.

Okay, maybe that was a stretch. But we have definitely found that if we add information in this seemingly chaotic way, we can reduce the chaos. No tag is bad, Bill. Convinced?

Pages has left the building...

AquaLogic Pages is now Generally Available, folks. Go and
Get It!

The world of work has just gotten a little bit easier...

Architecting for Participation

I was scanning feeds on Rojo last night, and saw this post about Steven Bao, and the Facebook apps he has created. He is 14. He's a freshman in high school.

What languages does he know? Java? Nope. But he knows PHP and MySQL, plus JavaScript and the rest... and he's learning C++. And of course he has his own company. At that point in my life I was trying a new skateboard trick, unsuccessfully.

Then I read a note about MySpace versus Facebook on TechCrunch, reinforcing the obvious.

A hallmark of Web 2.0 is that it is participatory, and as we delve into the enterprise we need to pay careful attention to this, not just from a feature/function perspective, but from an architecture perspective. Poll the enterprise today, and Java and .NET will be strong, poll the people hired in the last two years, and the LAMP stack and browser-side programming will show a steep rise. And if freshmen in high school are tooling away in these languages, just think what the work force will be like 5 years from now. All purveyors of Web 2.0 technology in the enterprise should take notice.

And what should the APIs give access to? Everything. If you're afraid of people doing themselves harm with your APIs, then either you don't have respect for people, or you have a bad architecture. Here's an idea: document the interfaces, and let people invent. If you seek to control the applications people build with your platform, then you are almost extinct.

Some people reading this will think he doesn't get it -- the things that matter in the enterprise are security, robustness, things not available in these new architectures. To you I say that you don't get it, innovations will fill the void, and that is exactly what we are trying to do. Embrace the architectures of participation, because you don't want to build for the past. Building for the future means being open, giving a big-ol bear hug to the emergent stuff on the web, and doing the heavy lifting to find ways for it to meet the needs of the enterprise. Because people will find a way to get their jobs done... either with or without the technology that their company wishes they would use.

Using Web 2.0 in the Enterprise today...

On Wednesday at the OReillly's Web 2.0 Expo in San Francisco, I joined Ross Mayfield, Joe Schueller and Michael Lenz at a panel titled Web 2.0 for the Enterprise: What Corporations Really Want and Use.

It was an interesting discussion, reported on by InfoWorld and InternetNews, and the questions indicated how much companies are hungry for practical guidance on adopting these modern tools within workplaces that might be, well, resistant.

When we were discussing the propensity of people to purchase wiki software with their credit card to begin collaborating without corporate approval, it was widely hailed as positive. The question is, how do you strike a balance? Ross, of course, didn't mind the credit card purchases. Michael, on the other hand, said he wanted to encourage people to use new tools, but instead of charge their credit card, it would be better to put it towards a common pool so IT could fund the right solutions to the problem.

That seems to put us back where we started, doesn't it?

When we were discussing Ensemble with an IT executive recently, he was intrigued, saying that he loved it at the same time they hated it. He desperately needed to wrap his arms around all of the rogue web applications in his enterprise without changing the way his people worked, and he was thrilled that it could do just that. After all, the minute you try to control people, they will find another way using consumer tools. But he worried about the air of legitimacy Ensemble would give these tools. In other words, while he was very pro-wiki, there were other rogue efforts he was trying to constrain, and having Ensemble made it harder to argue against them. After all, they were safe now, weren't they?

I say let your employees do what makes them productive, just give yourself the tools to govern and manage it. In other words, don't prevent people from misbehaving, but make sure that they are accountable when they do misbehave. Because in general, people surprise us in positive ways, especially when we do what we can to make their jobs more fun, or at least... less frustrating.

Have will, find way

In a recent study by McKinsey it seems that Web 2.0 adoption is being thwarted by nervous executives who fear two things:

IT ceding control

Disruption of the "knowledge economy"

IT ceding control...

This thorough study found that 33% of executives invest in wikis, 32% invest in blogs, while just 21% invest in "mash-ups." First of all, those numbers are big. Secondly, often there is more deployed than management thinks: almost no executive knows which wikis are out there. When we did a research roadshow in 2005 we asked companies how many unmanaged web applications were in their enterprise. Typically, people said they had very few. Then, we went through category after category (including wikis) and found that the average company had around 100 unmanaged web apps.

The article notes:

Jacques Bughin: "The reason why blogs and wikis, in particular, aren't well used is that companies are still afraid," he posits. "How do you basically regulate how to contribute?" He also thinks the wisdom of crowds isn't always sharp and that companies are worried about getting bad information on a collaborative document, such as a wiki.

The basics of these problems have been solved in a lot of wiki platforms (import your users from LDAP, use security, etc.). The remainder of the control problems are solved by Ensemble. As for getting bad information out of a collaborative document, it all comes back to traceability. If you know who edited what, when, using a page version history as well as a component version history you can easily solve this problem (Pages).

Disruption of the "knowledge economy"...

The conceit here is that since people are valued for their knowledge, recording their knowledge in a wiki threatens their status, so they won't contribute. Solution: celebrate the contributers, and let the others leave the company. Successful organizations of the future will be transparent, the idea people will be celebrated, and the knowledge hoarders will simply have no place. The first step? Put together the right feedback mechanisms to determine who is really valuable (in terms of contributing knowledge) in your organization. Yes, maybe this is a plug for Pathways.