Hmmmm .... having scattered conversations all over the place. So maybe it's time for a position statement about the whole widgets and social networks tip I've been on for a couple of months.
First note, when I first saw widgets popping up eg. Konfabulator, on Yahoo and Google etc. I didn't reckon much to them. What's the point of cluttering up nice clean web-pages with heavy, not all that useful, even if pretty, gratuitous little applications? Why not just have them as separate pages and keep a handy bookmark page?
Second note, I was a bit late into social networking, I didn't understand Ryze when I joined it. (Never went back.) I got into Tribe, but mainly for good conversations. No one I knew ever really took to it. Though I met some cool people. Friends did get into LinkedIn after a few years but that was kind of boring.
Never touched MySpace ... especially after it was bought by Murdoch ... and, well, Facebook etc. sort of passed me by ... until I started reading about Facebook opening up to 3rd party developers.
That captured my interest a bit, as a Platform Wars theme. But until I read some stories about the speed at which applications were taking off on Facebook and decided to investigate, I still didn't get it.
Well, widgets are not that exciting. And social networks are OK. But what suddenly struck me was that widgets + social networks are a lot more interesting ... from a developer's perspective.
A common criticism of "web 2.0" startups is that they're "features but not businesses". They are often tightly (beautifully) focussed on a single task, but they lack the context and infrastructure that could make a commercially viable unit. They aren't sufficiently compelling to attract customers to set up an account, to migrate their data, or to bring their friends. In a sense, they don't do customer relationship management.
What Facebook's move demonstrated was that it may be the infrastructure substrate on which "features" could have a hope of surviving alone. Social networks already have the user account / customer relationship stuff sorted. All your Facebook widget needs to do is hook into them.
What that means, if you think about it, is that we're banging the rocks together again. It's possible to think of software applications being pulverized into even smaller microchunks than current web-applications.
That's interesting in itself. Smaller, cheaper software tends to have big effects.
And it continues the most important long-term trend in software. At first, computer programs had to do everything for themselves. Then, with the invention of operating systems, much of the handling of input / output and disk management could be delegated to the O/S. On microcomputers, nevertheless, in the 80s, programs still had to handle their own fancy graphics until GUIs became available as a service that your software could tap into.
In the 90s, with the rise of web-based applications, yet more of the complex functionality of software was delegated to standardized services and components. Although we tend not to remark on it, web-apps were distinguished by their handing over storage responsibilities to a relational databases, while the building of complex forms was done by the browser.
Hold that thought ... and let's bring in John Hagel's assertion that companies are unbundling into three different kinds of specialist : those dealing with customer relationships, those dealing with infrastructure management, and those innovating new products. Now remember that, today, there's no real difference between business and IT, or between code and law, or between society and technology. So the evolution of software and the evolution of the business landscape are not merely metaphorical analogies, they are literally the same process. Both operating systems and OEMs are members of the same type : infrastructure outsourcing destinations.
The unbundling that Hagel predicts for business is enabled by, and mirrored in, software. The standardization and specialization in infrastructure continues apace with, say, Amazon's S3 and EC2. Or the recently announced Salesforce Force platform. Or the willingness of some web-companies to make their data-bases available for mashups.
But let's get back to Widgets in social networks. Or what I have started calling the "YASN-as-platform". Here we see the other side of Hagel's unbundling : the separation of product innovation from customer relationship management. What the YASN-as-platform does is make that true in software, it allows the product innovator or feature developer to treat the customer relation infrastructure as yet another service, to be accessed through standard APIs.
Everyone from Microsoft to Yahoo and Google to Facebook, MySpace, etc. are trying to turn the user or customer into a platform, accessable through software. In fact, Amazon, with their usual bluntness about such things have a service called The Mechanical Turk which is about making API calls to people. That may or may not work out for them, it's certainly innovative. But it's a little too blatant for comfort. But it's more or less what all the other YASN-as-platforms are going to be offering too.
Now, the oldest, dumbest version of this is just the old web 1.0 style "portal". Big company (Yahoo, AOL, MS, Netscape) acts as entry point for a lot of users and tries to cram a lot features + adverts on to the front page. It buys features from other, smaller developers. Smart users don't like it because it clutters their lives with unnecessary crap. And smart developers don't like it either, because their access to the user is mediated by the big company who call all the shots. In fact, typically, the developers have to sell *to* the big company, rather than directly to the customer.
And, frankly, apart from having the link in a prominent place, the big company in its role qua customer manager doesn't really offer much value to the product innovators.
With the rise of the YASNs, particularly the more savvy ones, we see a new breed of customer management company : they enable "edge" conversations and encourage customers to manage their relationships directly with each other. Users create new tribes, discussion groups, shared blogs or social networks. With the opening of Facebook, soon to be copied by everyone, they make their pitch to developers : "write for our platform and we'll bring the customers".
Which brings us up-to-date with a current discussion that's being had about the "closedness" of Facebook and the need for an open alternative. Let's focus on the positions put forward by some very, very intelligent thinkers in this area : Umair Haque and Dave Winer. Roughly speaking, you can say that both Haque and Winer see the new excitement about YASNs-as-platforms as misguided.
Haque has repeatedly stated that Facebook is Evil, recently highlighting its ongoing romance with Microsoft and tendency towards being a closed platform. Winer is eternally suspicious of the bad intentions of all platform providers, and smells trouble coming from Facebook's closedness and is calling for an alternative open standard.
They are both right, but I'm going to argue that they both ignore the potential of YASN-as-platform to offer real value through not being open (ie. not dissolving themselves back into the web.) And my prediction is that, for well or ill, these non-open platforms will become extremely successful and powerful.
Now, why don't Winer and Haque see this?
Well, I'd suspect that Winer, more or less does. As I once joked, Dave's business model is to give away platforms, sell ping-servers. The new YASN-as-platforms are not exactly built around ping-servers, but have at their heart something analagous : the ownership of a crucial communication infrastructure - one which is a curious amalgam of protocol, name-space and cultural practice. So Winer's concern is partly self-interest - he has a stake in defining new socio-technical convention infrastructures and wants his to win - but it's also moral, driven by genuine enmity to the abuses of power by platform owners.
Haque, I think, is misled by a mistake he shouldn't be making. One of his more astute observations is that markets, networks and communities are not the same thing. But you can summarize what's wrong with his position by saying that he's confused a network with a market and is advocating what would be good for a market for something which is really a network. In a market, virtues are freedom and openness to participation. In a network, virtues are primarily effective link-management and secondarily effective flows.
Regardless of the specific reasons (others can reach similar position just from an aesthetic revulsion at a return to web 1.0 style portals) the opposition to YASN-as-platform concludes that :
a) an open system would be morally more wholesome,
b) an open system would be technically as effective, if not more so
c) so either Facebook will eventually open up (dissolve itself into the web) or we should actively put the boot in by boycotting Facebook and embrace OpenID and then some open protocol for social-connection data.
Aside : as FOAF is dead-in-the-water thanks to the curse of RDF/SemWeb (DNFTT ;-) Winer's in with a chance of making it some OPML-type thang - as long has he can get Marc Canter on board and find some quick-win practical applications of friendship data. Except, like I say, this time it's not going to work.
The problem is that b) isn't true. In fact, there's a hell of a lot that a closed YASN can offer that an open rival can't.
Let me present exhibit 1 : the Facebook news-feed. Every person who installs a Facebook application can grant permission to that application to write to a news-feed about them and their activities that gets shown to all their friends. Think about that for a second, for a programmer that's like having /dev/people ! Do you want to output to the screen? To the printer? To these guys? These are friends, by the way, who have not necessarily installed your application themselves. So unless you're in the business of writing actual viruses or trojans, you've probably never had access to anything so viral.
As I hinted earlier, it's just turned human-relationship management into a service available to the programmer via an API.
Of course, it can and will be abused. At the naive level, you can imagine applications that are simply going to spam your friends. Or hard-sell your friends to install them. Nevertheless, we can hope for some tough counter-selective forces to start to work here. If you value your friends, you aren't going to let your applications harass them. And in time we can expect some applications that use this feature to provide real value.
Let's imagine a Facebook app. we'll call BabyRota : an application that let's young mothers co-ordinate baby-sitting with their friends. BabyRota offers the usual calendaring / appointment making that maybe dozens of apps offer on the web. Mothers can say when they're available to help out with baby-sitting for their friends. And can mark when they are going to be out and need someone to baby-sit for them. When two friends have installed the application and are logging their requirements with it, BabyRota can automatically find matches.
However, occasionally, when a mother can't find a match on BabyRota, she can hit a button and have a general announcement asking for help to be sent to all her friends via the news-feed. She may not have thought of her friend Steve as a likely candidate, but she does, at a pinch, trust him. And has no qualms about alerting him to the fact she'll be out this evening.
Now, the imaginary BabyRota application has a couple of interesting features :
1) it takes advantage of social-network data;
2) it has a strong requirement for control over privacy (we're assuming here that mothers don't want to broadcast the times they leave their house unoccupied to unknown strangers); and
3) it has a requirement to touch people who have not elected to install the application or to be part of the baby-sitting network.
I suggest that it's very hard to provide these features in an open system, outside of a walled-garden YASN like Facebook. Readers are welcome to try to persuade me otherwise, but features 2) and 3) are pretty inconsistent in an open context.
Technically, generating and aggregating feeds is a problem which has been well and truly solved. But you can't make this data available on public feeds without losing the privacy. On the other hand, keep the data inside BabyRota and you can't touch people outside it. The best you can imagine is letting users upload a list of friends' emails so that the program can spam them.
BabyRota's character depends on Facebook's news-feed - which is an unusual kind of beast. Starting with the fact that Facebook has got social-graph data which is independant of any particular application it has built a social convention - that it's OK for other people's applications to stick stuff on your home page.
And that's a convention which only exists within Facebook. It doesn't make sense to try to apply it outside. Because outside people haven't accepted it. That's why giving a non-Facebook BabyRota my email address-book to spam my friends won't work. Not because it's not technically possible, but because it's not socially acceptable.
I'm going to add two further contentions.
Firstly, the requirements of BabyRota are not at all uncommon. There are many parts of life which fit the pattern of "we want to do something privately in one application or network, but occasionally push it out, but only to a controlled extent". Think of companies which internally deliberate about purchases until finally releasing a purchase order to a selected supplier. I'm going to call this pattern "semi-permeable networks". Access from the outside is controlled in two ways : some people can see some things inside them.
Secondly, we can probably start to imagine many things like the Facebook news-feed. Things which are a combination of technical infrastructure, protocol, and social convention. Smart platform warriors will create and own these things. And the social convention will be nearly impossible to reproduce elsewhere, giving the platform owners very strong lock-ins. I suspect that Ray Ozzie's web-clipboard has the potential to become one for Microsoft, and this whole wave of YASN-as-platform is, as Umair worries, a huge opportunity for them to seize control. Facebook certainly have the potential to be evil in a way that Google don't.
How far can this go?
Well, when you think about it, social relationships are a very generic kind of thing. Most other relationships are merely special cases.
Tim O'Reilly has started noticing that there are a lot more social relationships than those which are currently represented in YASNS. Certainly "customer relationship management" as currently understood. But what about teacher / pupil management? Buyer / seller management? Doctor / patient management? Government / citizen management?
Why shouldn't I be able to start a company on Facebook by inviting someone to be my "employee"? Salary and contract requirements become part of the link meta-data.
Note that today, YASNs tend to offer a very restricted range of link-types and link meta-data. But, as Dave Winer has suggested, they ought to allow users and application developers to invent their own. In fact, that's got to come soon, either from FB or someone hoping to take them on. And when it does, we'll see YASNs become an instant construction kit for all kinds of "enterprise" software. Payroll, performance assessments, medical records, memos, time-sheets, tax-forms, work-flow : the whole paraphernalia of the bureaucratic enterprise will become widgetized as the firm turns itself inside-out.
Today Facebook is banned inside some enterprises. Tomorrow, it may all that holds them together.
Facebook, Ning, Salesforce (Force), Amazon etc. are constructing the next platforms which are of interest to developers; partly interesting because they make "grid" or "infrastructure" such as data-storage and computational power available. But the real revolution is the other side of John Hagel's unbundling - people management as infrastructure.
This brings many dangers : Hagel predicts the customer relationship companies will consolidate dramatically. And the fact that these platforms will own certain amalgams of protocol, name-space, infrastructure and social conventions will give them huge lock-in potentials.
But the value proposition they offer will be compelling enough to over-ride such considerations. Beyond cheap provision of infrastructure that value includes the social conventions that allow semi-permeable networks to share data spontaneously, and applications that work by accessing information that aggregates across applications and networks.
Because of this, application developers will move to these platfomrs. And they will write widgets - by which I mean very small pieces of software that are parasitic on the YASN-as-platform for storage, execution and most importantly, access to the user and her social-space.