KnowledgeForward

Computerworld reported today that Microsoft offered to buy Yahoo for $44.6B

Microsoft Corp. today offered to buy Yahoo Inc. for $44.6 billion in cash and stock to better compete with Google Inc. in the market for online services.

CEO Steve Ballmer made the offer in a letter to Yahoo’s board of directors yesterday, telling the board that he would release the letter this morning.

On a conference call this morning, Microsoft’s president of its Platforms & Services division Kevin Johnson called a combination of Microsoft and Yahoo a more “credible” alternative to Google in the online advertising and services market.

“By combining the assets of Microsoft and Yahoo, we can offer a more competitive choice for consumers, advertisers and publishers,” he said.

There have been rumors of this for quite some time:

• 2005: ZDNet speculated about Yahoo and Microsoft teaming up to better compete with Google: “As it turns out, in true enemy-of-my-enemy-is-my-friend fashion, Yahoo and Microsoft have a mutual problem in Google. … Given that Yahoo and Microsoft were already chummy with each other on the multimedia front, why not merge their walled gardens to increase the utility of both in hopes of heading off any more defectors (end users) from taking in oodles and oodles of Google (at the expense of everyone else). ”
• 2006: SearchEngineWatch blogged that “Yahoo & Microsoft Have Talked Partnering, Merging”
• 2007: BusinessWeek reported “In the battle of online search, Microsoft is again courting Yahoo, according to media reports”

Of course, you could probably pick any two technology titans and find enough written about them to connect a thread.  But this seems more than random chance since there are obvious synergies, but one issue that makes me question the long term value.

Looking at it from a marketing point of view it’s a very good move.  Yahoo offers strength in web advertising, social computing, and web-based email where Microsoft is weak.  They have overlapping (and expensive) assets in search and categorization that can be consolidated and trimmed.  They also offer great talent and intangibles around web 2.0 and a disruptive, creative mindset.

From an infrastructure point of view I’m a bit more dubious.  Yahoo seems to favor the kind of Java, Unix, and open source tools (Apache, FreeBSD, Perl, PHP, Linux) you’d expect out of a young company out to challenge the powers that be.  If Yahoo has a huge number of very bright programmers that are almost religiously dedicated to Unix-based platforms and development they may not want to switch.  For scale reasons I’m sure Microsoft would allow this subset of the company to continue along that Unix path (I’m not saying they’d force mass conversion at the point of a sword), but it would take some restraint not to try injecting Windows servers and .NET into newer offerings and slowly alienate the staff. 

So, in summary, I think from a financial view it probably looks good (win/win for both sides), from a marketing view it looks good (fills in weaknesses of Microsoft and allows for consolidation of operations), but longer term the risk associated with the assimilation of Yahoo into Microsoft (and therefore the odds of capitalizing on the assets they are acquiring) may be even higher than normal for tech companies.

I talked to the folks at Eluma today and got into an interesting discussion about how much people (enterprise information workers was the immediate concern) want their activities tracked and how much to let them know what is being tracked. Eluma is a web organizer (place to categorize and store the stuff you find on the web) with some social software capabilities underneath.  The conversation was around “Are people scared of all the things your computer keeps track of on you?  Should a product leverage tracking information to help a user find relevant information and, if so, how do you word that so it doesn’t sound like an invasion of privacy?”

This was a timely discussion for me since just yesterday I wrote a posting on Could Attention Data Become a Record? that introduced a fantasy scenario where a corporate executive insisting on innocence about malfeasance on his watch could be undone by all the tracking and attention data on his PC. 

There’s no doubt that privacy and web tracking are issues getting a lot of attention these days.  It’s fair to say the majority of my readers are not embezzling millions of dollars and trying to deny knowledge of the situation, but even us law-abiding folks don’t feel right about being tracked - particularly if we haven’t been told and don’t see the value ourselves.

If you want to see how concerns about web tracking are on the front burner just open up today’s Wall St. Journal.  On the front page of the Marketplace section (page B1) is an article called Watching What You See on the Web which describes how NebuAd helps an ISP to do “deep-packet inspection” by looking inside the packets sent by the user and selling an aggregate view of the user to advertisers who will target messages based upon the profile. 

Then turn a few pages and on page B4 you see an article called Facebook Rethinks Tracking which describes how Mark Zuckerberg has apologized about their Beacon program which enabled friends to get messages based on their web activity.

Personally, my focus is on enterprise information workers.  Accordingly, my interest is more in how tracking information and attention data can be used to help information workers to pull information that may be of interest closer to their focus and push other information further back.  To me, I think the keys to using tracking information for the benefit of information workers are:

• Being very clear about what’s being tracked
• Allowing opt-in or out of what’s tracked. As Evan Schuman of eWeek wrote ”a little more selling of the benefits and permission-getting might have made a world of difference.”
• Breaking open the “black box” (like a spam filter lets you check what it’s blocking) to check what it’s deciding

There is a line beyond which web users do not want to be tracked and the industry and users are feeling out where that line is drawn. As .com companies like Facebook try to cash in on their place as the center of conversations to monetize that stream, we’re going to see more companies stepping over that line through carelessness or to test the waters.  Will that line be tested and pushed back over time as other etiquette/decency issues like violence and suggestive behavior on TV shows has been?  Or will laws be enacting that equate deep packet inspection with wiretapping over the phone?

What is certain is that Google’s success at monetizing its attention stream has launched a gold rush.  Investors are demanding a payday from social sites that have succeeded in becoming free hubs for facilitating the buzz of blog postings, ratings, bookmarks, and music preferences.  And advertisers are proving willing to at least test the waters by showing up at the front door of these companies with bags of cash to get at the tracking data.  There aren’t too many companies out there like Craigslist that can resist this kind of temptation.

Whatever happened to the idea of owning your own content?  In the rush to jump on Web 2.0 bandwagons and start publishing every which way, it seems people have lost track of the idea of how to get a hold of their content.  Having import/export mechanisms is the first step. Having those exported files being in a standardized format that could be imported into another system is even better.

If you use on-premises versions of Enterprise 2.0 tools that gives you a lot more control.  But SaaS has become a popular distribution model for these types of services and it has a lot to recommend it.  The problem is that there aren’t easy answers to the questions any organization opening up an end-user content generation tool (e.g., discussion groups, wikis, blogs, social bookmarking/tagging) should be asking:

• How are we going to do contingency planning or do we trust the hoster with what may become critical business data? 
• How are we going to mitigate the risk of using a small vendor or a new product from a large vendor that may be ditched if a juicy acquisition comes along?
• How can we upscale the content that is generated by starting with a body of end-user content and taking it to a more professional, formal level?

These questions could be answered by providing access to the data in standardized XML formats.  At this point it seems the best answer is writing an application against the APIs (if they exist) to pull all the data out into whatever format you like or to utilize robots that can do huge amounts of screen scraping.  Hopefully standards efforts (like this one for wikis) can advance quickly before enormous amounts of enterprise content finds itself in a web 2.0 prison with no means of escape.

I spoke last week at a conference about how users make decisions between e-mail, IM, wikis, workspaces, the telephone, and other methods of communication and collaboration. I’ve seen many articles on when to use e-mail versus an IM, when to pick up the phone, what collaborative workspaces like SharePoint are good for, and they all seemed to be missing something, so I set about codifying my views on this topic into my presentation.

The point of my presentation is that there is an increase in web 2.0-like web content, communication and collaboration channels/workspaces and a corresponding increase in confusion about how to select among them. Ineffective communication and lack of collaboration caused by using the wrong channel or workspace can result in poorer understanding and decisions among the participants. Decisions about which tool to use are often made based on expediency, availability, and familiarity rather than productivity. This is natural and can never be fully optimized for productivity. But individuals and organizations can do more to increase productivity by encouraging appropriate use of channels and workspaces.

So what I’ve attached below is the “poster” version of the guidance I gave on deciding which communication or collaboration technology to use depending on the circumstances. It is just a starting point though - each organization may have a different set of tools or common usage. And there is still debate within my own team of how things should show up on this chart (hence “document libraries” appearing in two spots), so it should be taken as my personal best attempt at this guidance and not a formal, peer reviewed, locked down decision tree.

Some background is in order though: I don’t expect anyone to whip out this chart (or any guidance like it) every time they’re about to send an e-mail. You can only expect this guidance to affect systematic communicators (like corporate communications or HR groups that send important, polished messages to many people as part of their jobs) or those in training. There are certain “teachable moments” when guidance like this is accepted and has a chance of sinking in. Just emailing it out to the department out of the blue is likely to have zero effect (or worse since future attempts at guidance are more likely to be ignored as well).

The main point of the chart is that message senders should learn to distinguish between collaboration / communication and synchronous / asynchronous. It’s important for the guidelines you give to remain realistic and flexible, particularly with informal interactions which should not slavishly follow the flow chart. You should customize these guidelines based on the industry, environment, and role while leaving room for situational factors (like sensitivity of the message). And finally, try to understand and minimize barriers to proper tool usage where possible, such as by making sure information workers have easy access to and feel comfortable with the tools so that lack of familiarity doesn’t come into play when making tool decisions.

So, with no further ado, here is the chart I presented (click on the thumbnail for a full-sized version):

If you haven’t seen the video of a woman opening her 300 page iPhone bill, check out the article and link here.  I’ll admit - I’m not currently a fancy phone kinda person, so you won’t see me commenting a lot on the mobile industry unless I get assigned that as a research topic. However, brand management and information management are passions of mine and in those terms I consider this a minor disaster.

From my view it’s a cautionary tale in 3 ways:

• The potential for collateral damage to brand image from partnerships. Manufacturers of products endorsed by athletes have often had to deal with this type of problem. In fact, it has become so prevalent that some companies and sponsors of events have decided the risk of collateral damage outweighs the benefit and now avoid such spokespeople. Now it’s Apple’s turn. Apple has earned a strong brand image that associates them with sleek, streamlined, innovative (not tied to legacy), understanding young people, and hip. But their relationship with AT&T has resulted in a brand management issue that is getting heavy exposure (including CNN Headline News) that will associate “Apple” and “iPhone” with something non-sleek, tied to an old way of doing things, unhip, and abhorrent to the values of many young people.
• The Web 2.0 generation has massively greater power to embarrass large organizations than previous generations. Accordingly, large organizations need to allocate budgets massively greater than those of a generation ago to mitigate this risk through continuous monitoring of legacy and Web 2.0 communication channels as well as a general PR contingency plan for unpredictable disasters.
• Old information dissemination practices must be reviewed in light of new information demands. When the only thing a cellphone did was make calls (and expensive ones at that), a paper itemized bill made sense. Text messages are far more numerous (an astounding 30,000 for Justine) so the same format will be practically useless.  Even if one was interested in the information on those pages, they would have great difficulty finding and using it.

And to those people who say it’s her fault for not selecting e-bill, you should have to opt-in to a bill that may require being shipped in a box, not opt-out. And I don’t think one would reasonably expect that their paper billing would result in a few redwoods worth of itemization.

As information management increasingly imposes itself on everyday life, will our online lives be reduced to metadata? This thought occurred to me when I was pointed to a news story on a pseudo-celebrity that is now involved in a court case. But it’s not the article I found interesting - it was the metadata panel to the right of it.

The E! website (really, someone pointed me to it - I’ve never seen it before) has data sheets for celebrities it shows to the right of articles. The metadata consists of a photo, related stories, and metadata tags. In this particular case, the tags under her smiling visage are “Contraband, Rx, Rehab, Dawgs, Courthouse, Busted, Hookups”. That’s the complete list - don’t think there’s more depth to round the person out.

I looked around a bit more and found sometimes the metadata seems to be related to the story, such as in the case of a pair of married celebrities who earned themselves two simple metatags: “Courthouse, Weird”. While namecalling was considered rude when you were on the playground, it’s apparently de rigueur once the demands of information management, hyperlinking, and tag clouds come into play.

If you’ve led a public life to any degree, chances are there is currently a lot of metadata out there labeling you as one thing or another. And chances are it’s not a very nuanced picture. All the more reason to get your unfettered thoughts and feelings out into the blogosphere before your metadata defines you.

I’m hoping that my recent postings on mashups (see here and here) have served to point out that 1) mashups are easier to define as an attitude and “feel” than a strict technological definition and 2) that mashups are not something new, although the attention to the quick&easy end of the composite application development scale is a good thing

I’d like to now add a #3 to that list: 3) that a killer web services API is sticky, contagious, and gets the creator/hoster a lot of good attention.

See this example from the EMC Documentum 6 enterprise content management platform. I had a few conversations with Documentum about the importance of web services APIs and what kinds of things and level of granularity they should operate at. Those conversations may have had a positive effect because Documentum subsequently released their first set of web services APIs, which I thought fit the mold of what customers were looking for. With version 6 they have pushed this further and added a development tool:

– Documentum Enterprise Content Services: a new, Web Services-based API that simplifies development and integration with ready-to-use enterprise content services for easy integration with other enterprise applications within a Service Oriented Architecture (SOA). EMC’s new services interface was redesigned to eliminate Documentum specific methods and terminology and replace it with a vendor-neutral framework for working with content management functionality. These services enable developers with no Documentum experience to build ECM applications quickly and easily. This open, generic approach eliminates the “knowledge barriers” that get in the way of incorporating ECM functionality in all enterprise applications and business processes that deal with content

– Documentum Composer: provides a standardized environment for development and configuration tools that reduce the need for coding and facilitates composition of applications with reusable elements

I’m hoping that as vendors realize how powerful Google Maps has become in part because of the great API that has encouraged thousands of websites to create mashups that depend on it, they will also want to provide “mashable” APIs. “We want to be the Google Maps API of the xxx industry” is shorthand for saying that a vendor (or enterprise with B2B channels) wants to make available a mashable web service that is:

• Sticky: Once a website incorporates a web services API it is unlikely to remove it for quite a long time.
• Contagious: Every website incorporating the API acts as an ambassador to visitors that get ideas about how it could be used in their website. To quote an obnoxious 70’s shampoo commercial “And they’ll tell two friends, and so on, and so on, and so on …”
• Good attention: When the UI being integrated is branded or the source somehow easily recognizable, it acts as an advertisement for the infrastructure underneath.

In my previous posting on mashups, I described how the origins of mashups (quick combination of parts that weren’t meant to go together) don’t match the most common apps called mashups (Google Maps mashups or “mapsups”). I then wrote “So, if the most common example of mashups doesn’t fit the narrative of the mashup and its origins, does that mean mapsups aren’t mashups? Or that the word has evolved and, if so, what does it mean now?”

That day an article by Ben Worthen appeared in the Wall St. Journal (”‘Mashups’ Sew Data Together”, 7/31/07, B4). Of course the screen shot was a mapsup (journalists, please check out this mashup of Sudoku with numbers from flickr - a non-mapping mashup - to validate this isn’t a one-trick concept). But the non-technical, business-related focus of the WSJ would certainly force them to give a good definition that is declarative, binary, and unique right? Think again.

“Mashups essentially are a way to take data trapped in separate applications and combine them into new, hybrid applications”. Just “a” way - if there are others then what’s the difference? And portals don’t fit this definition? Is it that the pieces being combined can be placed on top of each other or aggregated versus side-by-side like in a portal? But Facebook doesn’t fit that definition. Does it have to use Web 2.0 rich internet application technologies like Ajax?

Maybe it’s a new subcategory. Is this an implementation of service oriented architecture (which states apps from piece parts like mashups as an end goal) or an alternate mechanism? Is this a type of composite application? But still, it has to be differentiated from other types.

And talk about giving a non-unique definition, a few paragraphs later the WSJ quotes another definition “A mashup ‘combines data from disparate sources into something that is more valuable than the sum of its parts’”. If it’s really combining data you’re after, don’t business intelligence (BI) tools do that? Or dashboards? Or are those mashups too?

I can come to only one conclusion: Mashup is a state of mind. It’s a way of doing things, not a new technology. Just like Web 2.0 is more of an attitude (be more social and networked, emphasize informal networks over corporate heirarchy, use the latest set of technology on the web, etc.) that can be applied to new and old tools, mashup is an attitude that says there are a lot of great things you can do quickly by ignoring detailed integration and just slamming different pieces together. Quick is a relative term - I created a Google mapsup in a few hours with some Javascript coding which may not be “easy” to some, but compared to how long it looks like it would take it’s pretty good. That’s as much a credit to the Google Maps API though as it is to the mashup concept.

If that’s true, then it isn’t appropriate to say “Mashups do xxx”. One should say “doing things in a mashup way enables you to do xxx”. But they won’t - the term has taken on a life of its own. And if it leads to people rediscovering technologies like portals, BI, and dashboards; creating new web-based composite application creation tools like Popfly or Yahoo Pipes; and attaching a new label to aggregated apps like Facebook then that’s fine with me.

I think I get this whole “mashup” thing, but there’s one part I’m still figuring out: why is a combo made with Google Maps considered a mashup?

To explain my confusion, I’ll start with some history. The term mashup is derived from the music world where it describes a song created by combining (generally overlaying) parts of other songs. I’d describe it as a “frankensong”. The term “mash” has implications of a forceful, less-than-orderly combination of things. If you check the dictionary, you’ll see definitions and synonyms for “mash” that include words like “violence”, “pounding”, “crush”, and (yikes!) “pulpy mass”. The implication is that the musical combination is supposed to be quirky, creative, and charmingly rough. The outcome should be “new” – a different vibe, emotion, genre. It should be an unintentional use of the pieces involved.

I can see how a messy Facebook page, with all sorts of seemingly disconnected content and media crammed next to each other to create a new and charming mosaic of someone’s life, would fit the mashup concept.

But take a look at everyone’s favorite web-based example of mashups: Google Maps. A client recently told me mashups should really be called “mapsups” because Google Maps seems to be the only example anyone can give! In fact, according to ProgrammableWeb, Google Maps accounts for 50% of all mashup API use. John Musser’s Mashup Feed shows 54% of examples leveraging Google Maps.

But are they mashups?

Google provides a mapping API that is used to provide geographic visualization. It’s not unintentional or hijacking something for an unintended use. It’s just an API. This is what it is for. It is no different than calling out to a charting API and, indeed, there have been visualization libraries for a long time for bar charts and geographic mapping (Microsoft MapPoint comes to mind). Maybe it seemed like a clever type of repurposing and combinatorial innovation to the first few people that saw mapsups, but they may have been uninformed about the code-calls-API underpinnings.

So, if the most common example of mashups doesn’t fit the narrative of the mashup and its origins, does that mean mapsups aren’t mashups? Or that the word has evolved and, if so, what does it mean now? I’ll mull that over a bit and publish my thoughts in another blog entry.

I’m starting out a little slow today after my first arena-scale rock concert in about 15 years - The Police. I used to go to several a year in my college days and had gotten used to the feel of them and their traditions such as lighters for the slow songs and guessing which song they left for an encore.

But I forgot we’re leaving in the Web 2.0 era, which has changed everything from politics to, apparently, rock concerts. When the opening notes of Message in a Bottle start up I look to the stage and from my vantage point I can see the screens of a sea of mobile devices glowing in front of me. Hmmm, I don’t remember that from Def Leppard ‘88.

The guy sitting in front of me is on his Blackberry about 50% of the time. Apparently the communal aspect of 45,000 fans around him isn’t sufficiently social for him, so he feels the need to constantly send emails to friends and family. Sample email (hard not to see the screen in the dark): “I’m at The Police concert with your daughter. Cool.”

As they work through the set list I am not at all surprised to hear most of the favorites off of their Greatest Hits album. And if there was any mystery left, it was eliminated by the Wikipedia entry that already exists for the concert listing the set list, encores (two), and tour dates.

When Wrapped Around your Finger started up a smattering of people held up lighters, but most of the crowd held up cell phones instead. The eerie glow of the cell phone screens was no substitute for the star-like effect of thousands of lighters.

The show went off well though. A few wrong notes, but not as bad as the show on May 31st. How do I know that? Because of Stewart Copeland’s blog entry that day of course (is this entry legit?). This is the Web 2.0 era. Cell phones instead of lighters, e-mail during the concert, recent pop events already chronicled in encyclopedia form next to World War II, and online journals from band members are now just par for the course.