Where's My TV Server

About 10 years ago I had this idea. The idea was to create a home media server that captured media, both from online and from over the air, and served it to PCs and TVs throughout the house. We called it MediaKing.

The problem was the idea was too big, and perhaps before its time. What ended up happening is that a small piece of the idea, a new way to interact with music, became ClickRadio, which was indeed funded in 1999, and launched in 2000.

In any case, what recently struck me is, 10 years later, how what we wanted to do has still not come to pass, though various attempts have been made. Steve Perlman of WebTV fame, created a company called Moxi Digital, and a product called Moxi. Moxi is essentially a shared DVR. On a Moxi you can record TV shows off the main DVR, which can act as a server to other TV sets in the house.

Perlman ultimately ran into funding problems and sold it to Digeo, a Paul Allen company. Paul Allen is the co-founder of Microsoft and a Billionaire. Unfortunately, Paul Allen's portfolio seems to be where all good ideas go to die. And so it has seemed with Moxi.

Moxi was a good idea, but one big problem is that it was positioned as a product to be sold to cable companies like your regular old cable box, instead of positioning it as a consumer purchase the way TiVo did. The cable companies have apparently not been that interested. I only know of one major cable company to use Moxi, and that is Paul Allen' Charter Communications.

In any case the interesting thing is I still want this product. I'd love to have a central server that stored the TV shows I was interested in. I'd love to be able to back them up, and to add hard drives at will. I'd love to be able to control and access my video from my PC. To put stuff on it and to access it from anywhere on the network.

Ok, so now cue the TiVo fans running in to say "We can do all that!"

Well not really. First of all, I really would like to just have one recording device and then satellite devices the way that Moxi works. This is cheaper, and just as important, with a central server, I don't have to think about where different videos are because they are all in one place.

Secondly, TiVo feels like this walled garden. There are parts that are very well done. But somehow it feels like trying to kiss with a rubber mask on. TiVo is around 10 years old and the kind of features I am talking about have taken years to get done, and then been done in kinda wierd ways. The TiVo only recently became internet aware. And they have had a god awful time with TiVo to go. These are not 10 year problems. We have been doing great video streaming on PCs for at least five years.

In short, while TiVo doesnt quite suck , really it just *almost* sucks. And I think no one wants to criticize TiVo because they are kinda the underdogs. And we like underdogs and don't want them to fail. But really, they have nearly killed themselves with really anemic product development. Nothing from them seems fresh and exciting. They have no substantive internet presence. They seem like they are just kinda resigned to get old and sit on the third floor watching TV until it comes to time to meet their maker.

How sad it is. And it didn't have to be this way. But no matter. Really, I just want my TV Server. Can't anybody help me?

I Want Data Visibility More Than Data Portability

Data portability has become a huge meme in the internet universe in the last six months. I am very supportive of the ideas behind data portability, but I am not sure that actual "portability" is really what I most want as a user.

Portability typically implies import/export. I can move my data from here to there. Certainly there is value to this, but it seems to me what I really want is a unified "data location agnostic" view of my data. For example, I'd love to be able to do a search in my data universe and find everything with the words "waterfront project" across all my data silos like Facebook, Google Apps, etc.

Similarly, I'd like to be able to relate a document I was working on in Google Documents to Mary Smith who exists in my universe as a Facebook profile. When I am looking at Mary Smith's profile I'd like to see that Google document listed somewhere since it is related to her. But I don't want to move the document to Facebook to make that happen. 

The point is, what I am really interested in is not porting data but connecting and unifying it. And I'd like some kind of dashboard from which I could really see and explore as much of my universe as possible.

And so it seems to me a good word for what I am talking about is data visibility as opposed to data portability.

This visibility concept really encompasses two elements:

1. I want to be able to do a full text search of my data universe.
   
2. I want to be able to connect items in my universe regardless of their type or location. For any given item in my universe I would then be able to see all the others items in my universe that relate to it. 
   

To geek out for a sec, to achieve all of this what is probably necessary is for as many applications to provide search APIs and unique identifiers for each data item. To make it universal we would also need some kind of "field availability" API that would let us see what types of fields can be searched.

But regardless of the tech specifics, this is a simple concept. It would facilitate a whole new way of thinking about and organizing our personal data universe. I think it would be incredibly helpful. Do you agree?

Adobe AIR Security

It seems there are some folks whining about Adobe AIR security. Security folks are wringing their hands.

Excuse me, but WTF. I don't get it. You are downloading a friggin application. To your computer. Hello... McFly!!!!!

Since when did we expect that apps we download to our computers could be trusted willy nilly? Haven't we always had concerns about downloads and trojans? What is new here?

Well the argument seems to be that AIR developers can write apps using techniques such that their app may be more vulnerable to attack from a third party. So even if you trust the developers intentions, that developer may leave their application vulnerable to evil doers.

But again, to me, this is not new, and is nothing unique to AIR. Its true that an AIR app may be attacked. But so can an app written in C# or Java, or C++, etc. Now the argument is that since AIR includes the WebKit web browser that within an AIR app, people may surf to places where Javascript can be run. And since AIR is like a browser, but with potentially fewer restrictions, that it may be possible for the app to be compromised if it does not follow good security practices.

It seems to me that all this just suggests certain real life truths. Reputation is important. Don't eat food that smells bad. Don't sleep in a dirty hotel. Don't use an application from a developer that does not have a good reputation. Or if they don't have a reputation and you want to explore, beware.

The bottom line here is we are talking *desktop* people. This means taking some personal responsibility for what goes on your computer. For each download, it shall be as it always has been. Caveat emptor.

The Death Of Brands: Case Study, The Oscars

Q: Why didn't I watch the Oscars?
A: Because I didn't care.

But its not like I haven't cared before. The thing is I am watching less and less TV, and I didn't know any of the movies, and few of the actors. So I had no investment. But the real problem is not just that I didn't watch. It appears no one did. Anecdotally it was already clear by talking to my friends, none of whom watched this year.

But the Nielsens don't lie. The Oscars, from a viewership perspective, was a train wreck this year. What does this say about our media landscape and the power of iconic brands, when one of the most famous media properties gets no more audience than a good networks series?

I think what it really says is something quite significant about the value and role of brands in modern culture. The Oscar failure is is a reflection of the fact that we are inexorably headed towards a day when brands, as a concept, mean absolutely nothing. The fact that it was "The Oscars" had exactly no value to me. Instead of watching the Oscars, I went out and had a drink with a friend.

In the old school it used to be that if you had a lot of money, and built up brand recognition, that this was like money in the bank. But this just isn't true any more. The pace of the Internet, and the breadth of available communications channels turns a brand into nothing more than a token that contains an approximation of your business or product truth.

This year, the product truth for the Oscars was... who cares? The storied brand history meant nothing. I didn't believe they would entertain me this year, so I didn't watch. It seems I wasn't alone.

The bottom line is for any company or product, you are really creating or maintaining a collection of truths. If the truth is good, people will like you. If it is not, no matter how much money you spend, failure is inevitable.

Adobe Introduces Windows Killer

Today Adobe is announcing the official release of Adobe AIR and Flex 3. While these announcements are not really news in that the products have been in beta, and usable for a year, today seems a good point in time to mark the official end of the Windows era.

With AIR and Flex, What Adobe is doing is building a platform to replace all operating systems as a development target, and the implications of this are profound.

For most applications it does not make sense to write directly to the OS any more. This movement has been underway for years as application developers have been increasingly writing applications for web browsers instead of for specific PC operating systems. But web applications have had two problems. First they just looked crappy compared to desktop apps. And second, they did not have access to the file system and other local resources that a standard application has.

Adobe's Flex is a developer tool that is built on top of it's ubiquitous Flash Player. Flex makes building sophisticated web applications, also called Rich Internet Applications (RIAs), much easier than writing apps to the Windows API. Flex apps are slicker than standard Windows apps, and seamlessly integrate with the web. At the same time, HTML/Javascript apps are starting to look very good. While Flex is more powerful that HTML/Javascript, for many apps HTML/Javascript is quite good enough.

Adobe AIR is a tool that allows developers to build Flex applications or HTML/Javascript applications that work on the desktop but have access to the Internet and can synchronize between the web and the desktop when offline.

What is strategically significant about these tools is that they give millions of web developers the ability to do almost everything a hardcore Windows or Mac developer can do in a way that is totally cross platform (Windows/Mac/Linux and maybe mobile someday). A typical web developer today has no idea how to build desktop apps, so this technology is a game changer for that audience.

At the same time, if you are writing with Flex and AIR or HTML/Javascript and AIR you are not writing to Windows, or for that matter Mac OS X. The strategic import of this cannot be understated. Having MS-DOS and then Windows as the world's most important software development platform has been Microsoft's single most significant advantage in its history as a software company. That advantage is gone.

Adobe's strategy is a death stroke to Windows as a strategic monopolistic platform. And Adobe as a software company with revenues north of three billion dollars has the muscle, the development community, and the momentum to fight this battle. They will not be "Netscaped."

Windows will be a money maker for years to come as a tool that end users care about. And to be sure, there is still significant strategic value to the platform. But as a "must have" because people need to run Windows compatible apps, as of today we can say that rationale is officially dead.

RIP Windows 2008.

Microsoft Needs To Stop Being "The Windows Company"

This morning one of my commenters suggested I should provide concrete solutions for Microsoft instead of just bashing them.

In an ongoing effort to be of service to my readers, I am going to provide a ten point plan next week. But until then, I will start with the most important issue:

Microsoft is no longer a software company. They are "The Windows Company".

This is a failing strategy. They are not opportunistic, and they are not focused on being the best platform but on being the best Windows promoters. Microsoft should be deploying substantial resources, perhaps most of their resources, as though they didn't even own Windows.

For example C# language and SQL Server database are great technologies many will never use because they only run on Windows. Owning tools is a huge strategic advantage, but only if they are relevant. Historically, Microsoft's power in large part, has come from the leverage of tools. Microsoft should open up their tools group to compete with the likes of Java and MySQL. They should go platform agnostic and open source because Microsoft's tools are, despite being truly awesome, becoming totally irrelevant. In so doing, Microsoft would immediately get itself back in the game.

More to come next week.

Microsoft: We're Going "Open". Yawn.

Yesterday, Microsoft announced they are not going to sue anybody for connecting to their products and they are going to make release for public use, documentation and APIs formerly only available to Microsoft employees. Included in the announcement are products such as Vista, SQL Server, and SharePoint.

My view, who cares?

The goal here is clearly to re-invigorate developer interest in Microsoft platforms. The problem for Microsoft is that I suspect almost no one will actually do anything to take advantage of the new documentation and positive Microsoft attitude. The bit of enthusiasm for this move seems like more of an I told you so regarding Microsoft's ultimate need to be more open, rather than anything really meaningful from a business perspective.

There was a time, four or five years ago, when people were really focused on interoperability with Microsoft's products. For the most part, that time has passed. Other more interesting standards have emerged and Microsoft really isn't the center of the software universe any more except with Office. Even though, through Windows, they still control the desktop, most people these days only write for the browser, which is, for the most part, standards based. People don't need Microsoft's fancy API's anymore.

And so, to me, this announcement is really a reflection of Microsoft's growing marginalization. Their impeding irrelevancy is, at this point, almost fully exposed, but they are trying to retain that last modesty protecting fig leaf. Unfortunately the wind is strong, and the fig leaf is not up to the task.

Race And Technology

I was struck yesterday by this post yesterday in Valleywag.

Its short, so this excerpt is most of the post:


Is there discrimination on Sand Hill Road? Of course. But most venture capitalists have enough sense not to express it. Most. One repeatedly successful entrepreneur tells Valleywag a recent anecdote which puts the "crass" in "meritocracy":

A VC at an unnamed firm blurted out, "Oh, thank God you're white" when my business partner and CEO walked in for their meeting. As way of explanation but without any embarrassment, the VC said that most of the founders they'd been meeting with were Indian or Asian. Needless to say, we cooled the discussions immediately thereafter.

Obviously, being African-American, this piece caught my attention. I don't think much about this stuff generally, but with the meteoric rise of Barak Obamba as the likely democratic presidential nominee and potential president, The Valleywag story drove me to try to reconcile the two concepts. Is America, and Tech America racist? And if so how do you explain Barack Obama?

In thinking about this issue, a few notions come to mind.

• Green is definitely more important that black, or white, or brown. Business transactions, at least in tech, I have felt are essentially colorblind.
• Hiring of course is not "a business transaction" in the same sense and is most definitely not color blind, as I can personally attest.
• There is still plenty of racism in America. The Younger you go the less there is. And by plenty, I don't mean by a majority. I just mean a relatively small number of people can do a disproportionate amount of damage.
• You only need 51% to win.
• It is exceedingly rare to hear anything directly racial, particularly in business, but it does happen. As in the Valleywag piece, it's usually "non-ethnic" friends and associates telling me some horrible thing some other "non-ethnic" person did, thinking it would be "cool." In these cases I often wonder why the inappropriate talker believes he can ever get away with inappropriate talk. In any case it is wonderful that these folks are occasionally indiscrete because you can't fight what you can't see.
• Ron Paul wrote in in a 1992 issue of the Ron Paul Political Report that "If you have ever been robbed by a black teenaged male, you know how unbelievably fleet of foot they can be." Despite this fact, he has received disproportionate and unrepentant support from many in the tech community, even after having been made aware of such statements. To me this does not represent racism in tech, but suggests a shocking level of insensitivity.
  

So what does all this mean?

The tech business is no worse than the rest of America on issues of race, and is probably better. Publicly exposed incidents like the one recounted by Valleywag re-expose slowly healing racial/ethic scabs and makes us all a little more wary. This kind of exposure is unfortunate, but also unfortunately necessary, because while we are good, we can definitely be better.


UPDATE: well I have my first of what I am sure will be many, Ron Paul defenders. The above should be enough. My commenter suggests that the above Ron Paul statement isn't offensive, just true. Amazing. Anyway just to nail the coffin shut, Another Ron Paul racist Tidbit:

"Given the inefficiencies of what DC laughingly calls the criminal justice system, I think we can safely assume that 95 percent of the black males in that city are semi-criminal or entirely criminal."

UPDATE 2: here's some more from Mr Paul.

"We don't think a child of 13 should be held responsible as a man of 23. That's true for most people, but black males age 13 who have been raised on the streets and who have joined criminal gangs are as big, strong, tough, scary and culpable as any adult and should be treated as such."

"We are constantly told that it is evil to be afraid of black men, but it is hardly irrational. Black men commit murders, rapes, robberies, muggings, and burglaries all out of proportion to their numbers."

Microsoft's Ray "genius" Ozzie fails. Plan B: Yahoo

Ray Ozzie is the CTO of Microsoft. Ozzie is best known for creating the workgroup product Lotus Notes, and more recently workgroup product Groove. When Bill Gates decided he was going to retire, he decided he wanted Ray Ozzie, who he lionized as a "rare genius," as CTO. So he bought Ray's company, Groove, to get him.

It should have been obvious at the time this scenario would fail.

Microsoft is a company that makes products that require compelling user experiences to succeed. It is, for the most part, a consumer facing software company. And of course the internet is *all* consumer facing. Experience matters.

Ray Ozzie could not have been more ill suited to leading such a company's product development.

Lotus Notes was a product that was never successful as an end user experience. I have never personally been a Notes user as I have always managed to maintain technical free will. But as far as I can tell, force is the only successful means ever employed to expose real human beings to Notes.

Nevertheless, Notes, by any financial measure, was a great success. IT folks loved it. It provided centralized control. Who needs end-user buy in. You will assimilated.

So after the Orwellian success that was Lotus Notes, Ozzie moved on to create Groove. This, I suspect, was a salve for his wealthy soul after creating Notes. Groove was another workgroup tool, but it would be driven, supposedly, by individual users instead of the CIO. Users would *decide* that they wanted to use it.

Only no one decided to use it. No one even understood it, or at least what it would be good for. In fact, famously, Joel Spolsky of Joel on Software called the Groove designers "Architecture Astronauts", meaning they were all about the architecture and far less interested in doing anything that users actually cared about. It was an incredibly famous post that triggered Ozzie himself to respond. Joel seemed to be channeling the entire tech world at the time with a giant WTF.

And so, no one got it. Except perhaps the most important audience of all, Bill Gates. Bill, inexplicably, decided that Ray was the man to lead Microsoft's technology into the future. In an increasingly end user driven world, Bill Gates hired a guy that had never made a product that end users ever actually wanted, as Microsoft's CTO.

And so here we are today. Microsoft is a distant third at best in almost every Internet category they compete in. Microsoft has failed at the Internet. The Yahoo play is just the ultimate "can't hide it now" admission of the obvious. More importantly, Ray Ozzie has failed. But my point here is not just that Ozzie has failed, but that his failure was entirely predictable.

Now Microsoft is running out to buy Yahoo in what would be the second largest tech acquisition after AOL/Time Warner. And indeed that will fail too. It is like attempting to merge a cow egg with hyena sperm in some mad scientist lab. The result will unfortunately, not survive labor.

And so, what of Ozzie. Will he continue to putter around Microsoft spreading fail pixie dust? How long can they continue to throw good money after bad, after bad? I don't know, but it is truly incredibly compelling theatre!

Who Needs Market Research?

This is a question that was brought to mind by the current episode of the NextNYers video series, where every week they interview entrepreneurs who are building companies in the New York area. This episode is about a company with an online video speed dating web service called Camlink.

Indeed it wasn't a bad interview, but the host, Courtney Nichols, asked one question that troubled me. She asked what sort of market research the company had done to determine if there was a market for this kind of product.

This, it seemed to me, was an unfair question, because it implied that market research is a needed and/or valuable way of determining whether a web service will be successful.

I don't generally believe this is the case.

In fact, I would go as far as to say that without actually building a consumer service, it is rarely possible to determine whether it will be successful. This is because with these kinds of products, the devil is in the experience. Who would have thought that Facebook would have been able to come into the market so strongly and to catch up to or beat MySpace? On paper, it would probably not have been compelling.

The only thing you could have perhaps determined from market research is whether people want to connect with each other. But the truth is it's like asking someone if they would prefer Coke with lemon or lime when they have never tried either. You can ask people if they like lemon. You can ask if they like lime. You can even ask if they get thirsty. But the only way to know what they really are going to like is to observe their behavior after trying both.

In this case, I don't think there is much question that there is a demand or need for tools to help people find dates, partners, or spouses. Will their particular approach work? I don't know, but I don't think any market research would tell me.

But this does bring to mind the question of how you determine if there is a market for a web product. I think the best way is by solving a problem that you personally relate to. Of course its never that simple, particularly if you do not have sensibilities that match those of the mainstream. No matter what, some combination of insight, luck, and execution will always be required, and indeed I think finding that sweet spot is more art and iteration than science.

For developers doing consumer web products, doing pre-launch market research surveys, or anything other than testing product usage is a silly exercise. Post launch, real market reaction is the only research you can really trust.

Outlook Sucks

Yes, I am biased. I used to be in the PIM business many years with a product called DayMaker. But I think I am past that now. And while Outlook may be a reasonable email client, in my view the contact/calendar/task features, or their implementation, *really* suck.

It seems to me that outlook is weak compared to all the online competitors for each category, from mail, to calendar, to contact, to tasks. It is true that nothing is really doing a good job of integrating all of that yet, but Outlook doesn't do a good job of it either.

Outlook's hold is purely that companies have standardized on exchange, and to the extent that people are uncomfortable with their data in the cloud, an exchange server has really been the only choice.

This really isn't an analysis, just a bit of a rant. I am curious what others think.

Others Agree: The Relational Database is Dying

note: My original and far more in depth thoughts on this subject are here.

Today on Read Write/Web, one of my favorite blogs, is an article that essentially mirrors my thoughts on relational databases and the semantic web.

Also, when I posted the original article, someone who seems to be a part of the W3 team working on the semantic web, referenced my original piece in a posting on the related W3 mailing list. He was using it to bolster his argument that the semantic web technologies are too complicated for mainstream developers, which is a core part of my argument.

This is a subject area that I and members of my team have been thinking about and working on for some time. It is always fun to see independent confirmation of the relevance of your work.

Disruptions

I have spent a fair amount of time in the last few days talking about disruptions. The core of the thinking here is not mine. The concept of disruptive technology was championed by Clayton Christensen, and has become somewhat old hat in tech circles. But its funny how sometimes we need to hear things we already know to keep us focused. And such has been the case for me in the last week.

I am always trying to think of disruptive stuff. I think the best definition of a disruptive product is when in many or most respects it sucks when measured in terms of quantity of features, when compared to incumbent products. But because it does one single thing so much better than the existing products, or because its metaphor is so powerful, you are willing to forgive its poor showing in raw feature wars.

This disruptive nature is critical to most new products that have incumbent competition, since it is unlikely you are going to be able to "catch up" to an already successful well funded company. Of course the kind of disruptions that Christensen talks about, like the change from horses to automobiles or telegraphs to telephones, are truly massive, and none of us should hold our breath waiting for that scale of disruptive invention.

And while the large-scale disruptions are unlikely I think the theory still holds writ small. One might think of them as "mini disruptions."

I say all this because it is easy to think in terms of whether or not a new product will stack up against an existing product in the marketplace. But this is not really the question. You really have to ask yourself whether the product you are developing will in some way, change the way people look at that kind of product.

A good example of this is Google Docs. Google will *never* have a more featureful office suite that Microsoft. But they do one thing much better than Microsoft, which is collaboration. If you want to work with someone else on a document, or share it with others, Docs is great and Office blows. Oh and Google Docs being free doesn’t hurt either.

I have been focused on this because there is a natural tendency in product development to start saying, "oh we need to add feature X because product Y which we will compete with has that too". And of course feature X is one of hundreds of features that product Y has that we won't have at launch.

And so you have to keep asking yourself, if I don't have this feature or that feature, but I have this other set of features that product Y will likely never have, is that an exciting product. Of course the answer is, it all depends. But this is the question that you need to keep asking yourself, because it is unlikely that you as a new company can win the feature war with a traditional ground campaign.

Bringing this back to me specifically, I spend a lot of time thinking about how to position our product initially. Is it as disruptive as we think it is? Will people get the paradigm shift? Will the consumer facing aspects be simple enough to get and yet radical enough to be exciting? Of course we don't know the answer to any of that for sure. But the one question I will definitively not be asking is if we have enough features. Because if the core concept is not appealing, features won't matter. And if it is, they won't matter either.

If You Want an iPhone, Get Something Else First

I have been using a Motorola standard feature phone for the last two years. It was falling apart and I needed a new phone. I really like the iPhone, but I really don't like the fact that it is not 3G. I don't want to drop four or five bills on something that I am going to want to replace in perhaps less than six months. And I rarely sell anything. Its too much of a pain. So if I buy it I typically own it for life until it hits the trash can. So selling and upgrading would probably not be in the cards.http://en.wikipedia.org/wiki/3G

So, though the iPhone is clearly king of the hill, I needed a way to stall. The problem is that my old phone was essentially dead, and was on Verizon, a CDMA network. I decided I really wanted to be on AT&T since it would allow me at some future point to get an iPhone without having to switch networks. AT&T is also a GSM network which means it supports SIM cards that allow you to easily switch between and experiment with different phones.

In the middle of all this thinking, AT&T launched a promotion: the Blackberry Curve for $99. The seeds of a plan start to come together.

I decided I would get the Blackberry. This works out incredibly well economically because the $99 price is a subsidized price that only comes with a new AT&T contract. The iPhone comes with no subsidy, so when you get a new iPhone with a new contract, you are throwing away the AT&T subsidy opportunity.

What I recommend for anyone intent on buying an iPhone is to get another free or cheap AT&T phone using the contract subsidy, and then get the iPhone. Even if you do it all the same day. Otherwise you are giving money away. If nothing else, get a free backup phone.

And so the very clear lesson learned from AT&T and Apple seems to be, if you want an iPhone, get something else first.

Database Application User Interfaces Suck

I recently wrote about what I called the death of the relational database. The premise of that article is that relational databases are not well suited to the dynamic nature of modern data management because modifying or extending relational data schemas is exceedingly difficult.

But another issue plagues database applications, which is the user interfaces they tend towards. Relational databases drive a certain type of user interface that is inherently difficult to understand.

To understand why relational databases lead to interface complexity, a little context is necessary. All relational databases are really graphs as discussed in the prior article, where records point to or are connected to other records. The difference is that in relational databases a specific *field* in a given record points to another record, whereas in a graph database, the record *as a whole*, points to another record. This difference is critical because while a relational database is a form of graph database, it is much harder to visually demonstrate a link between a field and a record as opposed to a record pointing to a record.

On the surface, it may not be clear why this is the case. For example, consider an invoice that has a payment associated with it. The invoice record has the check number as a field of the invoice. This check number is a pointer to the check object.

Indeed this interface is easy to understand, but only because we intuitively understand that an invoice might point to a check, and in any case we all know what a check is. But this kind of dependency is cheating. In circumstances where the user doesn't already have the data model in her head such linkages are not at all clear. For example, if the linking field, instead of a check number was an authorization id, it would not be immediately clear whether or not there was some authorization object that the authorization id was pointing to, and if so, what it meant.

What is typically missing in such user interfaces is actually seeing relationships between database objects in a more physical way. For example, it is much clearer to show that there is a relationship between an invoice and a check by representing them both on the screen, laying them out in such a way as to reflect the underlying relationship. For example, the check and invoice could be organized in a folder. Or they could be organized in outline form so that the check is indented and shown under the invoice. But whatever the visual metaphor is, the key is that the graph model allows for a more physical representation that is understandable by any user even when she has absolutely no pre-existing knowledge about the structure of the data.

The fundamental problem we are really pointing to here is that relational database applications tend towards designs that require too much spatial visualization. As I discussed in a previous article on user interface psychology, this is problematic.

For example, without being able to demonstrate relationships in a more physical way, the authorization id discussed above requires some text explaining what it is, or perhaps some button, which takes you to the authorization record. But actually pressing such a button would have the effect of changing your context, which may actually increase complexity, particularly if the authorization record is connected to other objects in the database who's relationships must then also must be explained.

To reduce the spatial visualization issue, standard relational UIs have to work hard to make it clear what the data represents. Or in many cases, designers simply abandon making the data model understandable as a design goal, and instead the interface is built around just following instructions with some kind of step by step wizard interface. This is fine for a data input operator, but for people who really need to understand what is going on, if this is their only interface into the system, it is a nightmare.

The economic impact of this relational database interface complexity is substantial. Each time a new relational database application is designed, a significant amount of money is spent designing interfaces to make opaque data relationships clearer. And yet, even with all of that design work, huge amounts of money are spent each year training people to use these applications. Companies like Siebel made billions of dollars helping people create these complex monstrosities, and then training people how to use them.

I posit here that moving away from the relational model can save businesses billions of dollars in lost productivity and development costs as applications inherently become more intuitively understandable. But there is huge vestigial momentum behind relational databases, and the resulting derived products are often painful to use. Indeed perhaps instead of calling the prior article The Death of the Relational Database, I should have just said, if we are not careful, the relational database will be the death of us.

A New Way To Think Of MVC. Introducing PBVC.

Yesterday I argued that companies need platforms in order to maximize their flexibility to respond to the demands of the market in the fastest possible way. Today I thought that many of you could perhaps benefit from from some more specifics. 

When you think about developing an application, many (most?) of you will think of implementing some version of the MVC design pattern which stands for Model View Controller. The MVC pattern specifies a way to separate the user interface (View) from the data (Model) using a messaging or event system routed through a Controller. But the MVC can be implemented in many ways, and the key to a good MVC implementation is what exactly the model is.

The model essentially represents your data. But does it represent data in a form that just reflects how you store the data in the database, or does it represent data in a form that reflects what makes most sense in the context of what your application is trying to do. When the later is the case, we call the data representation business logic.

Business logic typically handle requests for data by grabbing raw data from a database, modifying or combining that data with other data, and presenting that data in a way that would be most useful to the user interface code because it reflects the real application model instead of just how the data is stored in the database.

And so here we get to the core of what I am suggesting.

When I talk about the idea that companies need platforms, I am making a really specific argument about how to architect systems. What I am really suggesting is that the model be split into a platform, and business logic. The platform is designed to make it easy, or easier, to build and modify business logic.

What this means will be different for every company. But, to use a simple example, if you are a retailer, then perhaps the customer database, and the credit card transaction system are handled at the platform level because they are things that should always be the same no matter what. At a lower level, perhaps the platform also contains a data storage abstraction that handles all scaling.

Scaling is a great example of something that should never be of concern to someone focused on business logic. And the business logic developer should rarely be told that something can't be done because the system can't handle it, can't scale etc. The platform developer should be totally focused on serving the needs of the business logic developer by providing abstractions of core system functions and application requirements.

What we are really doing is adding one more layer to the MVC pattern. Instead of MVC, think PBVC, for Platform, Business logic, View, Controller. And while, on some level, this many seem obvious, the frameworks that many of us use do not suggest this level of granularity. And so while no MVC frameworks prevent this kind of layering, because of where frameworks stop, most developers will fully blend things that are platform related issues with things that are business logic, making code much harder to scale and maintain, and most importantly, slowing down reaction time in the marketplace. For many businesses that intend to scale and need to iterate rapidly, separating these two different layers and focusing on them independently can have a profound effect on the ultimate success of your business.

Companies Need Platforms

In the current market, the most important thing that a company must be able to do is react rapidly to the marketplace. It is not important to always be exactly right about what the customer wants. But it is important to understand clearly the arena you are playing in and to build a technology platform that will allow you to address as much area in that playing field as possible as quickly as possible.

Having a strong platform is key to being able to react to the market as conditions change. The only way to do this is to develop core technology and an organizational DNA that can quickly deliver what the market wants, even when what the market wants is unexpected.

In considering how to deliver such a platform, I am reminded of an old saying I used to have, which is that you can't hang an anvil on a christmas tree. In essence, this means that you must build a foundation that is strong enough to handle the eventual anvils that the marketplace will insist you hang on your product. Now to be clear, your platform will never be strong enough to handle all of the things the market will ultimately demand of you. You will always be in a position of shoring up your core infrastructure to handle the unanticipated twists and turns of the marketplace. But the better your core infrastructure is, the better off you are.

By way of example, I consider Amazon vs eBay to be the prototypical case study. Amazon understands that the key to their company is having a platform that they can hang anything on, and that is exactly what they have built with Amazon Web Services and other internal, highly leveraged technologies like Dynamo. Their platform will be key in ways that they can predicted and in ways that they can't.

As far as I can tell, eBay has no such flexible technology platform, and so when the market complains about their product, they are flat footed. They can't quickly respond to the product demands of their customers. Of course I am not familiar with eBay's internal development, but the fact that they are so slow to respond to the demands of the market suggests strongly that they do not have a flexible system that allows them to iterate and make rapid adjustments based on feedback -- otherwise they would have done it. To me this will bad for eBay's long-term health as it attempts to compete with Amazon.

So how might one apply this insight to one's own business?

When you are thinking about building a product or service, at some point you should consider how to build your internal process in such a way that it answers a broader question than the specific immediate product mission you are trying to tackle. I believe the best way to handle this is two internal development teams. This should break roughly down to the platform team and the product team.

Ultimately, in a platform/product split, the platform team's customer is the product team. But the platform team works on the foundation, based on the broad directives of corporate leadership. The platform developers are focused on performance, and some broader mission that should be set by company leadership. The needs of the product team obviously must drive the work of the platform team, but by decoupling these layers of development, you actually increase the ability of the company to respond rapidly because, when done properly, the platform team is building things that will satisfy current and future needs of the product team, but in more leverageable ways than the urgent product team would have done it.

This strategy is a bit like Seven Habits of Highly Effective People applied to an organization. In Seven Habits, Steve Covey talks about four quadrants in a two by two grid with urgent and not-urgent on one axis and important and not important on the other axis. Without the separation of platform vs product, you are always working on urgent and important. The platform/product split allows for a focus on what is important but not urgent, which is the quadrant you are likely to gain most business value from.

In any case there is no magic in this. A misguided platform effort still leaves a company unable to respond to the demands of the marketplace. But properly determining how to split the tasks of platform vs product and therefore urgent vs important can be incredibly valuable towards building an organization that can iterate rapidly. Rapid iteration is ultimately critical to being perceived by customers as responsive and by the marketplace as superior, and a strong platform can be key in achieving that iterative velocity.

The State of New York Tech

This Last Thursday I went to an MIT Enterprise Forum event here in New York. The discussion topic was how technology transfer from universities to the entrepreneurial world works, but I attended because the issue of the state of New York technology is in my view, not good, and I believe the connection between the university and business community is one of the core issues.

I have been extremely frustrated that there is a contingent of the community who seem to believe that none of this is an issue. I have had discussions on the NextNY mailing lists where people have provided a list of successful IT related exits as proof that the tech community in new york is vibrant. This to me is the community sticking its head in the sand.

One of the things I find interesting about this is that the people who think there is a problem seem more commonly to be on the tech side of things, and the people who don't think there is a problem tend to be more on the business/marketing side. I am not sure this will continue to hold as more people join the discussion, but it does make sense to me that the closer you are to the issue, the more obvious it is. Given that we had a room full of people directly involved in the technology issues, there was a strong sense that there is a problem here. Some of the most interesting and relevant points made by the panel were as follows:

• Panel moderator Brian Kelly, Director, Cornell Center for Technology, Enterprise and Commercialization, indicated that essentially all biotech in New York leaves immediately after getting funding.
• Panelist John Fox President and CEO, Innovation Fuels said that New York VCs are far more conservative and lose deals to the west coast because they are more aggressive. And since money is so much easier out west, people leave.
• Panelist Franklin Madison, Technology Program Director at ITAC, said that there is lots of IT in New York, but that it is buried in the infrastructure of New York and not as visible as it is in Silicon Valley.
• Chairman of the MIT Enterprise Forum, Bruce Bachenheimer, and Clinical Professor, Director of Entrepreneurship at Pace University asked which if any of the New York area universities are interested in helping students become entrepreneurs.

As separate corroboration that there is a problem, several days ago, Nate Westheimer, a New York entrepreneur and founder of BricaBox posted that despite posting ads in appropriate places, he has been unable to hire a PHP programmer. His ads have received *no* responses. Some might argue that this is because the market is just so good because everyone is employed. I don't think this is the right conclusion.

My personal interest is in trying to figure out a way to improve the technology community in New York, particularly as it relates to what I call "hard core" technology. The New York Tech Meetup is great, but most of the products we see are not solutions to hard problems. The tech often seems thin.

One of the more obvious tasks is getting the major New York area universities to encourage technology entrepreneurship or working in an entrepreneurial environment as an exciting career path. In New York, a disproportionate number of the computer science students are ending up working on Wall Street. I think it would be helpful if there was more of a spirit of creation in the New York computer science graduates, as there is in those from the bay area.

In any case, the MIT event surfaced all of these issues both on the panel and it lots of informal discussions afterwards. Lots of people approached me and wanted to tell me their war stories. It appears to me that there is serious problem bubbling up to the surface.

But the goal of this piece is not to complain, but to figure out how to move the ball forward. The first step of attempting to fashion solutions here has to be people from the various constituency groups coming together. As such, I would like to begin an ongoing dialog about the issue. Please leave comments below, or join the just formed http://groups.google.com/group/nyc-tech-boosters mailing list so that we can continue the conversation.

The page metaphor. It sucks.

The Web browser brought with it a metaphor which has dominated software development for the last 10 years: the page metaphor. I don’t think I need to explain this. Everyone knows what a page is. Ok, the page metaphor doesn't *always* suck. In fact it can be a wonderful thing. The problem of course is that every information and/or programming model is not well suited to the concept of a page.

Of course when you have a hammer everything looks like a nail. And when you have a web browser everything looks like a page.

And so, every information presentation model on the planet was refashioned as a web page. In many cases this has been fine. But in many others it is a bit like dressing up a pig in a prom dress. The bottom line is that for many things, the page metaphor really does suck.

What happened was that when the web revolution began, Interface development was taken over by HTML jockeys that had no idea about the dialog that we had been having in the preceding decade about how to make it easy to access and manipulate information. It was as if the preceding decade, which I call the decade of the user interface, never happened.

The primary reason for this disconnect was the fact that the tools we had for developing desktop applications were not available to people who wanted to create web accessible experiences. So everything that you wanted to create had to be refashioned as a page, or it wouldn’t work. This was a horrible thing for the state of the user interface art. But it is what it is, and it was what it was, which is to say unavoidable. People wanted everything to be web accessible and there simply were not tools capable of building on the lessons learned in the decade of the user interface.

And so, we regressed.

Everything became a page, and much of what was learned was lost. We now have a decade of people who really don’t understand the issues faced and the lessons learned in the past. Many of them even look at this history with some disdain, converting their more limited modern experiences into a virtue. They believe that this more constrained universe is just the "new way".

Fast forward to 2008, Ajax, Flex and the Rebirth of User Interface.

It has taken us living through another decade, the decade of the web page, for us to come full circle. With new tools such as AJAX, DHTML, and Flex, we now have the ability, finally, to create applications that look and feel like desktop applications. We can now fully leverage the knowledge and experience that we developed in the decade of the user interface.

For me personally, this is an exciting, though way overdue development. During the decade of the web page I will admit I never learned how to create a good web page. I went straight from desktop apps to Flash and then Flex. I just found the web metaphor far too limiting and constraining. Important though they are, I just couldn’t get into building web pages.

The Internet generation, and the decade of the web page have been critically important social, cultural, and economic drivers. But we have indeed lost something over the last 10 years, and while I am sure we will get it back, it is taking far too long.

And so, what many people, from pundits to civilians, consider to be a new revolution, is really just recovery of lost ground, tip-toeing towards a future of interfaces sucking just a little less.

New York Tech Meetup Review - February

Last night's New York Tech Meetup was the best since I have been going, which is at least a year and a half. If you want to see video of the event, you can check out CenterNetworks recap.

TheIssue

This is a very attractive blog aggregator. The way it works is its homepage is like a directory or a newspaper with links. The links point to articles, but what is kind of interesting is that the articles appear below in a frame that is maintained by theIssue. This allows you t browse while always remaining in the context of theIssue, making it easy to return once you have viewed the article. The publication is organized by human editors which, if they can afford it, seems like the best way to curate something like this because they will clearly find content, particularly for breaking stories, that can't be found via automated systems. It's well done. I suspect I will use it.

Aviary

Aviary is a set of online tools for creating content. This will include a variety of tools including vector drawing, video editor, 3d editor, etc. The tool they demoed was the image editor.

The image editor is impressive. The concept is that you can edit art in a Photoshop kind of way. The tools look slick and reasonably fast. But the amazing thing is the collaborative and business model. The idea is to make work public, and to allow others to modify that work. Its like the open source development model for art. Anyone can contribute. But even better, everyone along the creative chain can specify a cost/value for their contribution. And you can see all of the iterations of the item. I think this concept and the tools are revolutionary. Note that you don't have to make your work public, that just seems like the most interesting aspect of this.

Xerpi

Xerpi is a fancy bookmark manager. In this case, the fancy is a very good thing. After wasting a minute or two showing some silly Powerpoint, they actually got down to business and showed what I could best describe as bookmark pages. The idea is that you can create named pages. Within those pages you create bookmark groups. Within those bookmark groups you can put bookmarks. Everything is very drag and drop. You can make pages public, or private, or share them with a small group of friends. Elegant and simple. Well done.

Plink

The idea behind Plink is that you can visually mark your pictures in Facebook and associate areas of the pictures with commerce information. For example you could mark the watch that you are wearing in a picture of Facebook, and you can link that to an item in the Plink system. The idea seems to be to get people to link all the purchasable items in a picture to items in the Plink database.

What I can't understand is why anyone would do this. The user doesn't get a cut. And it seem kind of gauche to be marking up all of your pictures with e-commerce links. On the other hand it was a very slick implementation. This would work better as a part of facebook, but even then, without the revenue share I don't get it.

Launchbox

A Y Combinator clone.

This one disturbed Scott. He effectively pushed them off stage because they didn't have a demo because they are not a product. Launchbox is an incubator VC. To quote Scott, "this is not what we want here."

TakesAllTypes.org

Simple, beautiful idea. Apparently the blood supply in America is very poorly organized. Blood has a very short shelf life, and is not transportable over any significant distance. And when there is a shortage, it is typically of a particular type. There is no way to find and encourage people with a particular blood type in a given area to give blood. ItTakesAllTypes is a Facebook app that allows people to register their willingness to give blood. The idea is that when there is a shortage in an area, a message to all people with, for example, O-negative blood signed up in the New York Area, would be sent an SMS or email message asking them to come in and donate.

This is a super simple idea that really can save lives. Awesome.

TechPresident

This was the most fun of the night. It felt like my friend Andrew Rasiej, the founder of TechPresident, was going to start a fist fight with my friend Doug Krugman. Ok, well it wasn't quite that interesting, but here's how it went down.

TechPresident captures all sorts of interesting statistics about the presidential campaign. Andrew’s point was that Obama understands how to use the Internet better than Hillary, and that is why he is doing so much better with online support. Andrew showed a great user generated Obama video. Then he showed a really lame Hillary video. This is where things got interesting.

It felt to many as though Andrew was a clear Obama fan. People started shouting at Andrew. The Hillary fans were heckling him. They booed. “Is this a political speech.” Scott tried to insist that Andrew really is just making a non-partisan presentation about the numbers. It didn't hold water with the hecklers. Then Doug starts yelling out. Asking how Andrew knew the video was really from Hillary. Andrew pointed out that it had the Hillary logo on it, but Doug was undeterred. This went back and forth for a while but didn’t quite escalate to fisticuffs.

In short, it was a fun and exciting little bit of unexpected drama. Nothing like a Tech Meetup food fight!

The Death of the Relational Database

The relational database is becoming increasingly less useful in a web 2.0 world. The reason for this is that, while the relational database model is great for storing information, it is horrible for storing knowledge. By knowledge I mean information that has value beyond the narrow current conception of the given application. I mean information that can have enduring value. In this context, one might say knowledge is information in non-disposable form.

The reason the relational database doesn’t represent knowledge very well is that the relational database is only good at storing objects and relationships between them when one fully understands exactly what objects and what relationships will be managed upfront. When you need to represent some new type of relationship between the objects in a relational database, it tends to fail, or be very difficult. In fact, the relational database isn’t even particularly good at adding new types of objects to the database. Most relational databases actually have an upper limit on the types of objects, typically referred to as tables, which can be handled. Too many tables in a database schema is considered bad design.

The way I usually describe the situation is to say that the relational database is brittle but strong. As long as you don’t want to radically change or expand the scope of what you are doing, relational databases are great. But knowledge is an ever-expanding universe of objects and relationships between them. The relational database doesn’t handle that use case very well.

Storing the relationships between objects *in* the objects is a problem.

The essence of why the relational model doesn’t handle the more dynamic model of knowledge as opposed to information, is that relational databases are built around the idea that the relationship between objects is *built into* the objects. For example, invoices are typically stored as one type of object in a database. Customers are a different type of object. An invoice knows *as part of its structure*, who the customer is. That pointer to the customer is stored *in* the invoice.

This is bad.

The reason it is bad is because it means that in order to create new relationships between different object types we need to modify those object types. For example, if the developer decides to allow payment records to be connected to invoices, either the structure of the payment record or of the invoice must change. So, with a relational model, you really want to make all the decisions about the valid types of relationships between objects right from the very beginning because you don't want to have to modify the structure later.

“Excuse me Mrs. Smith. We require you to decide on all of your child’s friends for life before you go into labor.”

Think about this.

Needing to know your database structure upfront is like needing to make a list of all of your unborn child’s potential friends. Forever. This list must even include future friends that have not been born yet, because once the child’s friends list is built, adding to it requires major surgery.

This rigidity prevents most developers from trying to build knowledge. They just capture information. Data is stored in separate unchangeable relational silos. Every time we think of a new way to represent or expand information we just make a new silo, because adding to or modifying an existing silo is way too difficult.

The societal implications of this fracturing and splintering of information are profound. And yet, the converse is incredibly empowering. How great would it be if when we thought of a new piece of information that we want to capture, we could simply add it to our existing database? Or perhaps if we can add things this easily it is more like a knowledge base than a database. Such flexibility would mean that we would have the benefit of leveraging the new information in the context of the existing information, building newly accessible insights along the way.

For example, imagine starting out with a contact list. Some months later, you add a restaurants list. Some months later again, you decide it would be great to be able to capture, for each contact, what their favorite restaurants are. Ideally one would want to just establish a “favorite” relationship between a restaurant and a contact without changing the restaurant structure or the contact structure. This is a simple example, but the bigger point is that relationships between pieces of information will always grow more complex tomorrow than they are today. Capturing and leveraging new types of information to increase knowledge should be a key design goal of modern databases.

Those computer science guys are on to something with that graph stuff.

The concept of having relationships between objects be separate from the objects themselves is the core concept behind what is known in computer science as graph theory. Graphs are collections of pieces of information and the connection between those pieces of information. In a graph, the pieces of information are called “nodes,” and the connections between nodes are called “edges.” Computer scientists like graphs because they are a universal way of expressing literally almost any type of information.

Too many computer scientists spoil the semantic web stew.

The graph is the underlying model of a new highly discussed but rarely used data storage concept called the semantic web. The semantic web is really, in its simplest form, the idea that information on the web should be stored in databases structured like graphs. This would allow information on the web to be much more intelligently accessible and expandable in a way that relational database systems are not.

Sounds good.

Unfortunately, the semantic web is proof that while a little geek is good, but too much geek is, well, too much geek. The problem is that the people that created the semantic web were just way too smart. In fact if you read even the watered down Wikipedia description of the semantic web, it sounds like useless abstract gobbledygook. As a result, the semantic web is too great a leap from the tried and true relational database. In fact, it doesn't even feel like relational database users were a target audience for the semantic web architects. But whether they were aggressively targeting mainstream database developers or not, the gap between the two methodologies is far too great not only because the semantic web is hard, but because relational tools are being greatly simplified, which just increases the gap.

Specifically, newer technologies like the ActiveRecord system in Ruby on Rails, have done a great job at abstracting much of the mind numbing complexity out of the relational model. Now, along comes the semantic web just in time to make us all feel really dumb again. The semantic web makes the relational database model feel positively Fisher-Price. The semantic web is, and will be, for most developers, a non-starter.

Hey man, I just wanna build a little web app!

But the biggest issue with the semantic web is that it is really conceived to solve problems that your average everyday web developer just doesn’t care about. It is an ivory tower solution. Ironically, the concept of a graph representation of information is totally relevant to someone building a web 2.0 application. But the tools, languages, and methodologies of the semantic web do not have the scrappy, agile, PHP web developer in mind. And so, for most such web developers, the semantic web is irrelevant.

And so, the relational database is old and ill suited to the modern data management world. The graph model is much easier and more appropriate for typical web tasks. But it needs to be productized in a way that makes it easy for developers to fit it into their workflow.

Of course, once you start thinking of information as a graph, all sorts of interesting things become possible. There is much more to talk about, but for now this should be sufficient food for thought.

Why Are So Many Seemingly Great Companies Failing?

Recently, I blogged about an idea I called geek cred. There were those that disagreed with me when the article ran on Center Networks, but what is interesting is that the central concept of the article is being played out in a more accelerated basis even as you read this with the implosion of Motorola and the Yahoo fire sale.

A company has geek cred because the geeks look at it and say “they know what they are doing.” The boil down of it is that companies that have geek cred have great technological leadership and über geek ground forces, and geeks can see that. Hence geek cred.

A number of people responded to the Center Networks placement of that article, saying, in essence, that what really matters regarding whether your company is successful is whether your product is selling. But this is like looking at the cancer patient who looks healthy and saying “how could you be dying, you look great!”

What happens is that the geeks see the problems before the general market sees them. The geeks are the canary in the coalmine. The stock market analysts only see it after the product starts to fail in the marketplace. But geeks can see that a company is *going* to fail.

The geek can smell it.

And so it was clear that Motorola would fail way before the general market figured this out. So too, Palm. So too Yahoo. So too eBay. So too IAC.

My primary argumentative commenter was Drama 2.0. Yeah that’s his online name. I think he is like Batman, living an alternate secret identity.

His simplistic analysis was that all the companies that are successful are successful because they make products that people like. Therefore, geek cred is irrelevant. I can't comment on all of his comments because it would be too long. But I have picked a few representative comments that I believe tell the story.

Regarding my comments on HP Drama, 2.0 said:

Does anybody believe that the average consumer is sold on buying an HP printer or digital camera because they recognize HP's geeky history? Of course not. People buy based on perceived quality, selection and price.

The problem with this is that getting to quality, selection, and price is primarily about being amazing geeks and having great technology. HP *owns* imaging. They have the best people. And the scientists that are great at it want to work there. A management consultant cannot walk into a boardroom and say “our mandate is offer the best quality selection and price” that is trivially obvious. If all you had to do was *want* for that, then every market would have parity. In fact even *defining* quality is a geek issue. What does it mean? How do we prioritize features based on our capabilities. In the area of imaging, as in all other tech related fields, success is all about having the best geekocracy.

Regarding my comments on Yahoo, Drama 2.0 Said:

Claiming that Yahoo's lack of geek cred is going to do the company in has to be one of the most amusing comments I've read recently. Yahoo's problems have a lot more to do with mismanagement than lack of geek expertise.

This is one of the most amazingly stupid comments I have heard in a long time. People who think like this are the reason all of these companies suck. Because if it was all about management, then Terry Semel should have lead Yahoo to greatness. And though they have had awesome intermediate term success, by most measures, the world sees nothing but bad times ahead for Yahoo. Why? Very simple: they failed at search.

Search is perhaps the geekiest thing you can do on the Internet. It is incredibly hard. And Yahoo doesn’t have the best people and they don’t have the best technology. They are not thought leaders in search. As a result, they are losing market share every month. That will continue forever until they hit zero, whether they are part of Microsoft or not. They are just not good enough. So I guess if not being geeky enough is all about management then by that measure, *everything* that every company does wrong is all about management since managers make all the dumb decisions. How insightful.

Regarding my comments on eBay, Drama 2.0 said:

Meg Whitman led eBay to where it is today - a company with a $40 billion market cap. It's the leading auction platform on the Internet and one of the most recognized consumer Internet brands. The Skype acquisition may have been dumb, but overall, the people behind eBay are laughing all the way to the bank.

This, for me, is the Pièce de résistance.

By most accounts, eBay is in big trouble. Why? Because their technology has lagged woefully, while Amazon, a true geekocracy, is about to eat their lunch. Amazon understands that they are not a retailer, or a marketplace. They are a platform. They figure out how to connect buyers to products in the most efficient way possible. That means putting products in front of people in the optimal manner. It means creating technology that maximizes transactions. Th