From the archives. The recent NerdTV on Dan Drake inspired me to look at Information Letter 14, the last days of AutoCAD.
A good document from one of the founders assessing AutoCAD's competitive environment in 1991. Not the same environment today, of course, but worth reading to see how he thinks and what he looks for.
October 31, 2005
Scobleizer - the future of Web businesses
Scobleizer Silicon Valley got my attention: the future of Web businesses
Read it all.
So, here’s the new Silicon Valley business plan. You build a service. Add a Buzz Gadget (Google/MSN/Yahoo are working on more to come). Add a Monetization Gadget (Google calls that their Web Advertising Platform — MSN and Yahoo are working on their own). Mix and mash and we have a business.
Read it all.
Scoble should be fired, author tells Microsoft
Is this slightly off-topic? I don't think so, platforms are social as well as technical. And this is an interesting story of company blog strategy and dispute of world-views.
Some guy went to Microsoft and told them to sack Robert Scoble. (Longer description here)
Here’s my take. Fight the Bull are Cluetrain for people who can’t handle the lefty, hippy, anarchist vibes of the original.
In a sense, there’s a market for voice reframed for disciplinarian conservatives. For RageBoy’s aggressivity, but not the whole Gonzo package.
If that’s what they’re selling, it’s vital for them to establish their credentials in opposition to the Cluetrain wing (which I take Scoble to be a manifestation of).
Fight the Bull offer salvation not by liberating the individuals to speak honestly, but by stamping out the obscurantist (intellectual?) tendencies of your employees. Of course they need to smack-down Scoble (who’s own book is coming soon) and signal their compatability with the overbearing boss : “Not in my company, man”
Update : Interesting. I left a comment on Scoble's blog which was pretty much the same as the above and it's now gone. (Moderated away by Scoble?) Is there something outrageous about this?
Some guy went to Microsoft and told them to sack Robert Scoble. (Longer description here)
Here’s my take. Fight the Bull are Cluetrain for people who can’t handle the lefty, hippy, anarchist vibes of the original.
In a sense, there’s a market for voice reframed for disciplinarian conservatives. For RageBoy’s aggressivity, but not the whole Gonzo package.
If that’s what they’re selling, it’s vital for them to establish their credentials in opposition to the Cluetrain wing (which I take Scoble to be a manifestation of).
Fight the Bull offer salvation not by liberating the individuals to speak honestly, but by stamping out the obscurantist (intellectual?) tendencies of your employees. Of course they need to smack-down Scoble (who’s own book is coming soon) and signal their compatability with the overbearing boss : “Not in my company, man”
Update : Interesting. I left a comment on Scoble's blog which was pretty much the same as the above and it's now gone. (Moderated away by Scoble?) Is there something outrageous about this?
October 30, 2005
del.icio.us didn't scale either :-(
The RSS blog says :
Not surprising, I guess. Anything with a central server is gonna hit scaling problems if it gets popular. Time to dust off all those old P2P treatises from 2001. :-)
It would seem that del.icio.us has joined Technorati, Feedster, BlogPulse, etc. in the Web 2.0 applications that don't scale very well. Posting new links to del.icio.us seems to fail for me more times than it succeeds.
Not surprising, I guess. Anything with a central server is gonna hit scaling problems if it gets popular. Time to dust off all those old P2P treatises from 2001. :-)
October 29, 2005
The fragility of Google Base and Ning
Nova Spivack argues that services such as Ning will be brittle because of the interdependencies between data-schemas.
I think this is very much something which will have to be seen in practice rather than reasoned beforehand.
If Sue's schema is relied on by others will she be so cavalier in making arbitrary changes? Or rather, there are two scenarios :
Novack points out that
But let's look at what has to happen for the SemWeb version to take place.
Someone has to define the ontology. Who is going to do that? We can imagine one of two scenarios. Either Sue is going to define the ontology by herself, or she is going to sit down with Joe, Lisa and Bob and define it communally.
Either case raises awkward questions.
All arguments I've seen for the SemWeb fall into this dilemma. Either there's explicit co-operation and SynWeb solutions would work as well. Or there's no explicit co-operation, but you're going to have to be extremely lucky to find that the ontology is sufficient to make interesting inferences to combine the data (in this example, to translate between Sue's and Joe's respective schemas).
Briefly stated: As the number of unique data schemas created in such systems grows, the probability of applications that use those schemas breaking also grows (perhaps exponentially).
Here's why:
Let's say that Sue creates a new schema in Ning (or Google Base) for a "Person." They make an app that uses this record structure. Now Joe makes a calendar app that takes Sue's Person record and connects it with his own unique "Event" record schema. Joe's app relies on Sue's Person schema to work. Next, Bob makes a To-Do list app that uses Joe's Event schema and Sue's Person Schema and pumps out "To-Do-Entry" records. Finally, Lisa creates a Project manager app that uses Sue's Person schema, Joe's Event schema, and Bob's To-Do-Entry schema, to pump out "Project" records.
So we have a network of apps that rely on data schemas from other apps. Next, let's say that Sue decides to change one of the attribute-value pairs in her Person schema -- perhaps changing it to map to a string instead of an integer value. That 1 simple change has huge ripple effects. First it causes Joe's app to break, which then causes Bob's app to break, which causes Lisa's app to break, etc. In other words, we have a chain reaction of broken apps.
As the number of unique schemas increases, the likelihood that a given schema will be modified in a given time frame also increases. At the extreme end of this curve, with large numbers of users, schemas and apps, the likelihood approaches 100% that at any given time some schema that is directly or indirectly required by a given app will have changed, causing that app to break. So in other words if such services are successful, apps within them will break ever more frequently, causing endless problems for developers.
I think this is very much something which will have to be seen in practice rather than reasoned beforehand.
If Sue's schema is relied on by others will she be so cavalier in making arbitrary changes? Or rather, there are two scenarios :
- One is that only Sue's schema is copied, and if she then wants to change it, presumably Joe can just stick with the original schema.
- Alternatively Sue's data is being actively consumed by Joe, and the applications will need to be kept in sync. In this case, things will depend whether Sue actively wants her data consumed by Joe :
- If she does, she'll have a strong incentive to not break his application by not changing her schema, or to co-ordinate with him for a negotiated change.
- In the worst case, where we presume Sue is not actively helping Joe, Joe will have to keep his application tracking the vaguaries of Sue's updates, and will probably try to insulate those applications downstream from him by wrapping Sue's data in a more stable format. Even in this worst case, we presume Sue is not going to be changing her schema arbitrarily every week.
Note that consuming eg. XML data is not really like scraping HTML. HTML can change rapidly because site owners experiment with the appearance of their pages. On the other hand, a pure data format is only likely to change when the application needs to represent new information.
Novack points out that
This is the very problem that the Semantic Web was created to solve. The Semantic Web provides tools for data schema integration and interoperability. The base value of RDF and OWL is that they provide a means to define, publish and map between data schemas in an open way. So for example, application creators can map their unique schemas to centrally agreed upon ontologies enabling the best of both worlds: individual developer freedom and global standards.
But let's look at what has to happen for the SemWeb version to take place.
Someone has to define the ontology. Who is going to do that? We can imagine one of two scenarios. Either Sue is going to define the ontology by herself, or she is going to sit down with Joe, Lisa and Bob and define it communally.
Either case raises awkward questions.
- If Sue is working alone, for her own benefit :
- a) what's her incentive to do the extra work of defining an ontology over and above her schema?
- b) given that Sue is defining her schema and the ontology, it seems likely she'll define the ontology to have roughly the same representational capacity as her schema. But, as noted above, data schemas are normally only changed when you discover you need new representational capacity. When Sue updates her schema, it's likely that this is going to be due to a new requirement which also isn't captured in the ontology.
- If, on the other hand, Sue is explicitly working with Joe et al, then defining a shared ontology for their work is just one way of defining a common exchange format. For years, common formats have satisfactorarily allowed different applications to work together without a combinatorial explosion of incompatibility. It's not clear why we imagine Ning-like programs unable to do the same. (Although I confess my ignorance of Ning here, perhaps there are technical restrictions that prevent this?)
All arguments I've seen for the SemWeb fall into this dilemma. Either there's explicit co-operation and SynWeb solutions would work as well. Or there's no explicit co-operation, but you're going to have to be extremely lucky to find that the ontology is sufficient to make interesting inferences to combine the data (in this example, to translate between Sue's and Joe's respective schemas).
October 28, 2005
What I'd do with Ning
Umair Haque : What's really disruptive?
I'd suggest it's better to stick to "disruptive" in the Clayton Christensen definition, as something the incumbents can't get into because it's worse (or useless) from the perspective of their existing customers.
In this sense, I see Ning as being genuinely disruptive, if you consider it as a web-development platform in competition with Microsoft's Visual Studio, IIS, database products etc. Or with similar Java based web-middleware from Sun, or even with Ruby on Rails and other free offerings.
Although Ning is "worse" in the sense that it builds a limited range of applications, it might be able to build the applications most people want. But MS or Sun couldn't get into it without abandoning their existing developer customers who have more sophisticated requirements and are already commited to their own existing codebases.
If I was running Ning, I'd be adding a few rather bread-and-butter useful apps like weblogs, discussion forums, issue-trackers etc. And aggressively selling it (with training courses, online documentation, screencasts etc.) to small web-development agencies as an alternative technology for building stuff for their clients.
I'd charge these small development agencies for an advanced product that allowed them to more fully wrap the applications in their client's branding, for hosting, and for the ability to "compile" Ning apps. into something that could be taken away and hosted elsewhere.
Ning has the potential to disrupt Microsoft, Sun, IBM and everyone providing web-based / enterprise software. And a great deal of the free toolkits as well. (Personal note, can we have Python-Ning as well as PHP?)
A web-centric development platform is the necessary requisite for the web-as-platform, and Ning has a chance of being it.
Update : as mentioned before. The one giant who doesn't have a current stake in web development platforms, and is therefore a good match for Ning, is Google.
I'd suggest it's better to stick to "disruptive" in the Clayton Christensen definition, as something the incumbents can't get into because it's worse (or useless) from the perspective of their existing customers.
In this sense, I see Ning as being genuinely disruptive, if you consider it as a web-development platform in competition with Microsoft's Visual Studio, IIS, database products etc. Or with similar Java based web-middleware from Sun, or even with Ruby on Rails and other free offerings.
Although Ning is "worse" in the sense that it builds a limited range of applications, it might be able to build the applications most people want. But MS or Sun couldn't get into it without abandoning their existing developer customers who have more sophisticated requirements and are already commited to their own existing codebases.
If I was running Ning, I'd be adding a few rather bread-and-butter useful apps like weblogs, discussion forums, issue-trackers etc. And aggressively selling it (with training courses, online documentation, screencasts etc.) to small web-development agencies as an alternative technology for building stuff for their clients.
I'd charge these small development agencies for an advanced product that allowed them to more fully wrap the applications in their client's branding, for hosting, and for the ability to "compile" Ning apps. into something that could be taken away and hosted elsewhere.
Ning has the potential to disrupt Microsoft, Sun, IBM and everyone providing web-based / enterprise software. And a great deal of the free toolkits as well. (Personal note, can we have Python-Ning as well as PHP?)
A web-centric development platform is the necessary requisite for the web-as-platform, and Ning has a chance of being it.
Update : as mentioned before. The one giant who doesn't have a current stake in web development platforms, and is therefore a good match for Ning, is Google.
Bubblegeneration on web 2.0
Umair Haque has a couple of interesting posts on Web 2.0
Haque doesn't think this is a good idea :
Genuinely disruptive ideas are hard to sell to incumbants. And web 2.0 doesn't fix this problem. By designing to sell to the giants, you become conservative.
At the same time, compare Paul Graham's assertion that
So individually, the incentive isn't there.
Maybe a different take on this is that all those "keep your data on our central servers" sites may play well with customers and complementary services, but are fairly viciously rivalrous with similar services. It's not really easy (or sensible) to divide your email consumption between Yahoo and GMail.
Thus centralized database web 2.0 companies are in pretty zero-sum competition with each other. In which case, something that could help Yahoo to destabilize Google might well be welcomed by the former.
People are too focussed on the original web 2.0 business models when they should be looking at yet further ones.
In particular, Umair seems to want to promote things that distribute the money for participation yet more evenly through the community. A good egalitarian sentiment I can agree with. But I'm not sure the reason is simply companies are too obsessed with existing business models. I think a lot of these people are (at least in their role as strategists) "greedy". They don't want to share the spoils more than they can get away with.
Google's AdSense was disruptive because it shared a lot more in return for a far larger base of customers and partners. I'm sure this could happen again, but there is a limit. Advertising works when where it's placed has enough spare attention that it can share a little bit with an advertiser. A popular web-page might just have that. But something smaller, eg. an hCalender record might not have spare attention to share with the advertiser.
Not saying I disagree with Haque exactly, but the lack of new advances in business models may be partly "people are not adventurous enough" and partly "it's pretty difficult to find them".
And I do disagree with the critique of amateurism. There are going to be amateurs (a lot) because some things will not be monetizable. Shirky's argument will still hold even with newer business models. Some things will be too small, (low value to this individual), to justify the decision making or attention sharing necessary to micropay it.
BTW : I wonder if Haque knows Weed?
Web 2.0 is too geeky :
web 2.0 services like minimalism (think Google's original clean layout) which reduce transaction costs but don't attract the mainstream. The answer is to partner with existing major players to get better known (and maybe educate a wider public about the virtues of your way of doing things.)The shape of Web 2.0 is a natural monopoly :
Part of what he's getting at here, is that traditional media is based on having an exclusive right to a broadcast channel and therefore audience. Web 2.0 giants are still giants. And startups are aiming less to "disrupt" the market than to get bought by Yahoo, Google, etc. It's portal theory again. Each startup really wants to be incorporated into one of the mega portals.Haque doesn't think this is a good idea :
I think these are kind of the wrong incentives for entrepreneurs. What made the Valley cool was it's refusal to think small, and do truly disruptive things. But getting a small change acquisition to essentially extend a Yahoo/Google/etc product line sets incentives for incremental, not disruptive, innovations and models.
Genuinely disruptive ideas are hard to sell to incumbants. And web 2.0 doesn't fix this problem. By designing to sell to the giants, you become conservative.
At the same time, compare Paul Graham's assertion that
Success for a startup approximately equals getting bought. ... you either have to get bought or go public, and the number of startups that go public is very small.
So individually, the incentive isn't there.
Maybe a different take on this is that all those "keep your data on our central servers" sites may play well with customers and complementary services, but are fairly viciously rivalrous with similar services. It's not really easy (or sensible) to divide your email consumption between Yahoo and GMail.
Thus centralized database web 2.0 companies are in pretty zero-sum competition with each other. In which case, something that could help Yahoo to destabilize Google might well be welcomed by the former.
Success vs. success :
People are too focussed on the original web 2.0 business models when they should be looking at yet further ones.
In particular, Umair seems to want to promote things that distribute the money for participation yet more evenly through the community. A good egalitarian sentiment I can agree with. But I'm not sure the reason is simply companies are too obsessed with existing business models. I think a lot of these people are (at least in their role as strategists) "greedy". They don't want to share the spoils more than they can get away with.
Google's AdSense was disruptive because it shared a lot more in return for a far larger base of customers and partners. I'm sure this could happen again, but there is a limit. Advertising works when where it's placed has enough spare attention that it can share a little bit with an advertiser. A popular web-page might just have that. But something smaller, eg. an hCalender record might not have spare attention to share with the advertiser.
Not saying I disagree with Haque exactly, but the lack of new advances in business models may be partly "people are not adventurous enough" and partly "it's pretty difficult to find them".
And I do disagree with the critique of amateurism. There are going to be amateurs (a lot) because some things will not be monetizable. Shirky's argument will still hold even with newer business models. Some things will be too small, (low value to this individual), to justify the decision making or attention sharing necessary to micropay it.
BTW : I wonder if Haque knows Weed?
PC Pro: News: Google to launch eBay competitor?
PC Pro: News: Google to launch eBay competitor?
The first effect of all this, of course, is to make structured microcontent and microformats much more widely known and talked about. Then it's gonna associate them with making money.
Might this be the step too far in the web 2.0 bubble? Will everyone think that structured metadata will create a bigger market than eBay? Or that if they only add a couple of tags to their classified it will sell faster and for more money?
OTOH, what's to stop eBay adding some XML templates and competing head on?
Or maybe if Google really go for this, eBay gets into bed with another search-engine - Yahoo or Microsoft - to build a searchable XMLified market?
The first effect of all this, of course, is to make structured microcontent and microformats much more widely known and talked about. Then it's gonna associate them with making money.
Might this be the step too far in the web 2.0 bubble? Will everyone think that structured metadata will create a bigger market than eBay? Or that if they only add a couple of tags to their classified it will sell faster and for more money?
OTOH, what's to stop eBay adding some XML templates and competing head on?
Or maybe if Google really go for this, eBay gets into bed with another search-engine - Yahoo or Microsoft - to build a searchable XMLified market?
All your 'base' are belong to Google | News.blog | CNET News.com
All your 'base' are belong to Google | News.blog | CNET News.com
Plenty of versions of this story going round. Too tired tonight, will post thoughts tomorrow.
Plenty of versions of this story going round. Too tired tonight, will post thoughts tomorrow.
October 27, 2005
OPML, incremental development, Winer's gardening etc.
Re : OPML, Scribe says :
Yep, and the evidence from everywhere is that the second is better than the first. That's what "worse is better" means. It's the basic message from "How Buildings Learn" (old buildings are more freeing) and the main insight of xtreme and agile programming (do one user story at a time) It's why a complete Longhorn rewrite was guaranteed to be late (and probably not much good) while Unix derivitives will roll all over it.
The reason is clear. If you start with something that works for one application, and then hack it for a second, you're only having to solve one problem at a time. If you try to produce something generic, up front, you're trying to imagine and solve all the problems at once.
Of course, as programmers we all know that indescriminate hacking can go wrong. But that's in the situations where you don't balance the hacking with the requisite golden rule : you have to keep refactoring to keep your system flexible and in good shape.
XP doesn't advocate incremental, test-driven development, except with a great deal of refactoring to eliminate redundancy. What Ward Cunningham calls "working the code". Stewart Brand, in HBL, calls this "the romance of maintainence".
Now, it might seem strange to apply this to a format like OPML which is, by definition, pretty much fixed and not going to be continuously maintained and improved.
But in fact, OPML isn't a fire-and-forget format. It's the ecosystem as a whole which is the platform. You should interpret Dave Winer's work gardening and tending the whole OPML ecosystem (much as he's done with RSS, podcasting etc.) as the equivalent of continuous maintenence and integration.
Hacking includes Winer's careful provision of the plumbing for the ecosystem : hosting for blogs, shared outlines, ping-servers etc; it includes the search for new applications and new connections that can be made with other developers and users. Even the sometimes petulant complaints about rivals "confusing the user" or "sabotaging" the standard are, in fact, a kind of maintainence; weeding out the rivals.
That last is not necessarily a good thing, but I'm starting to suspect it is significant for the overall health of the platform. Les Orchard won't make a public spectacle of himself to defend XOXO. Winer will to defend OPML. He's continuously needling, exploring, selling and otherwise refining its "use" pattern on the internet.
In this sense, Winer implicitly understands Shirky's rule that you can't separate social from technical. The platform is the combination of the two. (In fact, all platforms are, which is what makes them so fascinating.)
I don't know if the competitive pressure on OPML is actually all that great. No-one except Dave is really promoting a vision of shared outlining. There are people writing better outlining clients, who'll support OPML anyway. And people who come up with rival formats for the aesthetic reason of "doing it properly" but aren't passionate about shared outlining as a platform.
Unless these two factions have some reason to make common cause and deliberately try to destablize the OPML ecosystem I don't see it. The biggest danger to OPML is that people just won't really get what it's all about and so it languishes in obscurity.
Actually, I can see a potentially huge rival for the widespread adoption of shared outlining : wiki. If I have to bet between shared outlining / OPML, and some kind of wiki (perhaps distributed between lots of clients with transclusion etc.) I'm probably going to bet on the wiki. (But perhaps I'm biased :-)
I think there's a difference between something that's been generically designed, and something that gets hacked into new situations.
Yep, and the evidence from everywhere is that the second is better than the first. That's what "worse is better" means. It's the basic message from "How Buildings Learn" (old buildings are more freeing) and the main insight of xtreme and agile programming (do one user story at a time) It's why a complete Longhorn rewrite was guaranteed to be late (and probably not much good) while Unix derivitives will roll all over it.
The reason is clear. If you start with something that works for one application, and then hack it for a second, you're only having to solve one problem at a time. If you try to produce something generic, up front, you're trying to imagine and solve all the problems at once.
Of course, as programmers we all know that indescriminate hacking can go wrong. But that's in the situations where you don't balance the hacking with the requisite golden rule : you have to keep refactoring to keep your system flexible and in good shape.
XP doesn't advocate incremental, test-driven development, except with a great deal of refactoring to eliminate redundancy. What Ward Cunningham calls "working the code". Stewart Brand, in HBL, calls this "the romance of maintainence".
Now, it might seem strange to apply this to a format like OPML which is, by definition, pretty much fixed and not going to be continuously maintained and improved.
But in fact, OPML isn't a fire-and-forget format. It's the ecosystem as a whole which is the platform. You should interpret Dave Winer's work gardening and tending the whole OPML ecosystem (much as he's done with RSS, podcasting etc.) as the equivalent of continuous maintenence and integration.
Hacking includes Winer's careful provision of the plumbing for the ecosystem : hosting for blogs, shared outlines, ping-servers etc; it includes the search for new applications and new connections that can be made with other developers and users. Even the sometimes petulant complaints about rivals "confusing the user" or "sabotaging" the standard are, in fact, a kind of maintainence; weeding out the rivals.
That last is not necessarily a good thing, but I'm starting to suspect it is significant for the overall health of the platform. Les Orchard won't make a public spectacle of himself to defend XOXO. Winer will to defend OPML. He's continuously needling, exploring, selling and otherwise refining its "use" pattern on the internet.
In this sense, Winer implicitly understands Shirky's rule that you can't separate social from technical. The platform is the combination of the two. (In fact, all platforms are, which is what makes them so fascinating.)
I would argue, that competition threatening the niche position of OPML is probably considerably larger (and quicker to innovate alternatives) than the world of Operating Systems - especially when viral factors ("everyone else has it") are taken into account.
I don't know if the competitive pressure on OPML is actually all that great. No-one except Dave is really promoting a vision of shared outlining. There are people writing better outlining clients, who'll support OPML anyway. And people who come up with rival formats for the aesthetic reason of "doing it properly" but aren't passionate about shared outlining as a platform.
Unless these two factions have some reason to make common cause and deliberately try to destablize the OPML ecosystem I don't see it. The biggest danger to OPML is that people just won't really get what it's all about and so it languishes in obscurity.
Actually, I can see a potentially huge rival for the widespread adoption of shared outlining : wiki. If I have to bet between shared outlining / OPML, and some kind of wiki (perhaps distributed between lots of clients with transclusion etc.) I'm probably going to bet on the wiki. (But perhaps I'm biased :-)
Joel on Software - Web 2.0 - what is it?
Joel on Software - Web 2.0 - what is it?
Don't know why I'm wasting my time ranting over there. But still, here's a copy of my post defending "web 2.0"
Don't know why I'm wasting my time ranting over there. But still, here's a copy of my post defending "web 2.0"
My God! Is this some kind of international whingers convention?
Lighten up! "Web 2.0" is a blatantly tongue-in-cheek term.
As for the thing itself, who cares what it's called? Or how "new" it is? Or that it's basically a marketing term?
The important point is somebody is trying to make fashionable a bunch of good ideas which smart people have been advocating for years, but the "common sense" of the industry kept denying.
Anyone who hasn't noticed that blogs have become popular and important; or that wikis are kind of useful, and surprisingly better than you might have guessed first time you heard the idea; or that RSS is a very cheap and simple way of doing something that 10 years ago people were trying to sell you million dollar workflow systems for; or that sites built to let customers talk to each other are more interesting than sites built as corporate brochures; basically hasn't being paying attention.
Does anyone remember what it was actually like in web 1.0? When the pointy-haired bosses thought the web was another channel to be colonized by big media; and that content was to be horded away in walled gardens and doled out to greatful, passive consumers? Or that it was OK to erect technical barriers to prevent customers from leaving a service? Remember when technical conversations were trade-secrets that mustn't be allowed out of your company? And when what Joel does here would be considered commercial suicide? Remember when sites were wannabe TV adverts rather than something to help the user?
What we can hope web 2.0 means is that finally people are going to understand what Joel and Cluetrain and Philip Greenspun and Dave Winer and Jakob Nielsen and all the other people who *did* understand the web, were trying to say all those years ago.
Six Apart - Mena's Corner: The Ups & Downs of a Successful Service
Six Apart - Mena's Corner: The Ups & Downs of a Successful Service
I'm only linking this because it reminds me that scaling issues can have non-linear effects. Here's a succesful service, who's use is increasing, if not linearly, at least following some, presumably smooth curve. But then a particular hard limit is reached : the data-centre capacity, which requires a sudden, step-change at the server end, and there are an accumulated stack of problems.
Many growing services, particularly web 2.0 companies with central servers, are going to be prone to this kind of thing. Such disruptions can potentially kill an incumbant and offer an opening for a rival.
I'm only linking this because it reminds me that scaling issues can have non-linear effects. Here's a succesful service, who's use is increasing, if not linearly, at least following some, presumably smooth curve. But then a particular hard limit is reached : the data-centre capacity, which requires a sudden, step-change at the server end, and there are an accumulated stack of problems.
Many growing services, particularly web 2.0 companies with central servers, are going to be prone to this kind of thing. Such disruptions can potentially kill an incumbant and offer an opening for a rival.
Ben Hammersley: The Hegelian dialectic of syndication formats
Ben Hammersley doesn't have much time for The Hegelian dialectic of syndication formats
I do. Or rather, let's get one thing straight. Here on PW we like the fite. It's not called "wars" for nothing. This ain't just a generic "cool new stuff in the blogosphere" blog. It's all about competition, rivalry, network externalities, exclusion and zero-sum games ... The more vicious, bitter and personal, the better. ;-)
There can be millions of standards in the world, but attention is a scarce resource, and we can't pay attention to, and develop for, all platforms at the same time. So some will win, and some will be consigned to the dustbin of history.
Also, I'm not ashamed of being partisan. Although I reserve the right to swtich sides whenever I like.
Case in point. It's kind of blatantly obvious to me that RSS 2.0 has currently won the syndication war. Ordinary syndication feeds between blogs and news sites and aggregators, are going to be RS 2.0 (although not for this blog, of course, because it's on Blogspot, which is run by Google, who've taken their own partisan position. This is fun in itself.)
OTOH, as as is made clear Atom does a lot more than simple syndication. It's possible that one of these other uses might take off in a big way, and that will have some effect. For example, if developers are having to include the standard Atom library in their code for other reasons, then it might be easier for them to produce an Atom feed than think about RSS.
So if Atom wins, it will because Atom syndication will have been aggressively bundled with other Atom functionality.
One thing that's interesting. This insistence that RSS 2.0 is fixed. It guarantees stability, but may, in the long term hurt it. Obviously we need fixed layers to build on (think internet protocol or http) But these are often not backed up by a rhetoric of "fixedness". If anything, the RFC convention generally caries an assumption that stuff can be revised eventually.
How important is a strong explicit rhetoric of fixedness in attracting or repelling developers?
Finally, I'm a critical rationalist, so obviously I think dialectics is bunk. But if we take it seriously for a moment, Hammersley is applying it wrong. The triad has to occur in time, and RSS 1.0 precedes RSS 2.0. The real triad would be something like RSS 0.9X (thesis - easy but no namespaces), RSS 1.0 (antithesis - generic, formally correct, but complex), RSS 2.0 (synthesis - a bit more extensibility with namespaces, not much more complex). Atom is the antithesis to RSS 2.0 as the thesis of a new triad. We wait to see what the synthesis will be.
I do. Or rather, let's get one thing straight. Here on PW we like the fite. It's not called "wars" for nothing. This ain't just a generic "cool new stuff in the blogosphere" blog. It's all about competition, rivalry, network externalities, exclusion and zero-sum games ... The more vicious, bitter and personal, the better. ;-)
There can be millions of standards in the world, but attention is a scarce resource, and we can't pay attention to, and develop for, all platforms at the same time. So some will win, and some will be consigned to the dustbin of history.
Also, I'm not ashamed of being partisan. Although I reserve the right to swtich sides whenever I like.
Case in point. It's kind of blatantly obvious to me that RSS 2.0 has currently won the syndication war. Ordinary syndication feeds between blogs and news sites and aggregators, are going to be RS 2.0 (although not for this blog, of course, because it's on Blogspot, which is run by Google, who've taken their own partisan position. This is fun in itself.)
OTOH, as as is made clear Atom does a lot more than simple syndication. It's possible that one of these other uses might take off in a big way, and that will have some effect. For example, if developers are having to include the standard Atom library in their code for other reasons, then it might be easier for them to produce an Atom feed than think about RSS.
So if Atom wins, it will because Atom syndication will have been aggressively bundled with other Atom functionality.
One thing that's interesting. This insistence that RSS 2.0 is fixed. It guarantees stability, but may, in the long term hurt it. Obviously we need fixed layers to build on (think internet protocol or http) But these are often not backed up by a rhetoric of "fixedness". If anything, the RFC convention generally caries an assumption that stuff can be revised eventually.
How important is a strong explicit rhetoric of fixedness in attracting or repelling developers?
Finally, I'm a critical rationalist, so obviously I think dialectics is bunk. But if we take it seriously for a moment, Hammersley is applying it wrong. The triad has to occur in time, and RSS 1.0 precedes RSS 2.0. The real triad would be something like RSS 0.9X (thesis - easy but no namespaces), RSS 1.0 (antithesis - generic, formally correct, but complex), RSS 2.0 (synthesis - a bit more extensibility with namespaces, not much more complex). Atom is the antithesis to RSS 2.0 as the thesis of a new triad. We wait to see what the synthesis will be.
Danny on the SynWeb
Danny gave a thoughtful response to the SynWeb stuff
I started a reply, but it got long and isn't finished yet. Coming soon ...
I started a reply, but it got long and isn't finished yet. Coming soon ...
Joel on eBay / Skype and architecture astronauts
Joel on Software - Tuesday, October 25, 2005
Joel says EBay lost the ability to code new stuff (unlike Google et al), so had to buy their way into new competencies.
He also rants against Web 2.0
I'm happy to be sceptical over the next bubble (though please can I be on it this time?) but I wouldn't dismiss web 2.0 too quickly.
Clearly, there's nothing really new about web 2.0 stuff. It's just a rebranding of what smart people have been saying right all along : that the killer app. of the web is letting people communicate and work together, enabling them to act rather than treating them as a passive consumer demographic.
There's a certain amount of fuzziness, and attempt to squash fashionable but not terribly relevant things (AJAX) into the story. But at least they are talking about what were the good ideas rather than the bad ones.
It is, of course, one of OReilly's manufactured memes like "open source" and "P2P" - the latter of which inspired Joel's original anti-architecture astronaut rant. However, here I don't see any "architecture" claims. There are "patterns", yes, but not the same kind of oversimplified abstraction as P2P.
Joel says EBay lost the ability to code new stuff (unlike Google et al), so had to buy their way into new competencies.
He also rants against Web 2.0
I'm happy to be sceptical over the next bubble (though please can I be on it this time?) but I wouldn't dismiss web 2.0 too quickly.
Clearly, there's nothing really new about web 2.0 stuff. It's just a rebranding of what smart people have been saying right all along : that the killer app. of the web is letting people communicate and work together, enabling them to act rather than treating them as a passive consumer demographic.
There's a certain amount of fuzziness, and attempt to squash fashionable but not terribly relevant things (AJAX) into the story. But at least they are talking about what were the good ideas rather than the bad ones.
It is, of course, one of OReilly's manufactured memes like "open source" and "P2P" - the latter of which inspired Joel's original anti-architecture astronaut rant. However, here I don't see any "architecture" claims. There are "patterns", yes, but not the same kind of oversimplified abstraction as P2P.
October 26, 2005
Is "scraping" the new spam?
Of course, we approve of deep-linking, or remixing and repurposing other people's data and content. That's the remix culture of web 2.0. :-)
But there's a real cost when scrapers become a burden on the sites providing the data.
Intuitively it seems to me that this active consumption of Craiglist's resources by Oodle makes this a different case from the current Google vs. the publishers fracass.
Google has a negative externality on publishers. By providing the same information that's in the books it reduces their sales. However, it's doing this without placing any active burden on the publishers.
The conflict between Google and the publishers is between business models. Whereas publishers still have a business model which involves restricting information (to those who've bought the book), Google's is based on the refusal of intellectual property rights to sell more service.
In the Oodle vs. Craiglist case, Craiglist doesn't seem to be "ostensibly" complaining about lost sales but about the actual use of it's computer time and energy (a genuinely scarce resource). Here one business model is simply parasitic on the ongoing work of another agent.
Will be interesting to watch how people feel about each of these cases. Which business models will get valorized? Which rejected?
Update : follow on article
But there's a real cost when scrapers become a burden on the sites providing the data.
Intuitively it seems to me that this active consumption of Craiglist's resources by Oodle makes this a different case from the current Google vs. the publishers fracass.
Google has a negative externality on publishers. By providing the same information that's in the books it reduces their sales. However, it's doing this without placing any active burden on the publishers.
The conflict between Google and the publishers is between business models. Whereas publishers still have a business model which involves restricting information (to those who've bought the book), Google's is based on the refusal of intellectual property rights to sell more service.
In the Oodle vs. Craiglist case, Craiglist doesn't seem to be "ostensibly" complaining about lost sales but about the actual use of it's computer time and energy (a genuinely scarce resource). Here one business model is simply parasitic on the ongoing work of another agent.
Will be interesting to watch how people feel about each of these cases. Which business models will get valorized? Which rejected?
Update : follow on article
October 24, 2005
Alternatives to the Semantic Web?
Danny Ayers asks about Alternatives to the Semantic Web?
My rant got pretty long, so I've put it here. (This is also notice, that Platform Wars is now going to be my main place for talking about the Semantic Web, as it mainly interests me as a battle-ground between some rival theories.)
My rant got pretty long, so I've put it here. (This is also notice, that Platform Wars is now going to be my main place for talking about the Semantic Web, as it mainly interests me as a battle-ground between some rival theories.)
[quote]One of the reasons the Semantic Web vision appeals to me is I lack the imagination to think of alternatives[/quote]
Sure you can. Take the defining feature of the semantic web (the URI) and negate it. :-)
[quote]and it also seems to make sense to use URIs as the key identifiers. Er… but that’s the Semantic Web.[/quote]
Agreed (with second part). And that's the crux of the matter.
I'll suggest the alternative to the SemWeb is the SynWeb, a web which doesn't need "key identifiers". A world with lots of online data, marked up with syntactic cues which make it easy to parse (eg. good old fashioned XML, or Markdown or YAML); more powerful tools and libraries for parsing and querying data with these formats; plus lots of programs which scoop up the data and combine them in interesting ways.
The difference is that the knowledge needed to give semantics to the data resides in the programs which do the combining, rather than in a schema which has been prepared earlier.
Why is this "better" (easier, more plausible)?
Because it's much easier to decide what something like an "author name" means at the point where you're producing and consuming it - ie. in the context of an application which actually wants that information - than it is to correctly determine what it means in advance, in general, for all possible producers and consumers[1].
This is the way meaning works everywhere else - eg. in natural language, the meaning of a text depends on the interpretations made by the author and the reader, in the pragmatic context of what they're communicating about. It's not formally fixed as the sum-total of the meanings of all the words.
Could the SynWeb bring all the benefits of the semantic web?
Most of them. In the sense that any particular application you can think of that requires that someone write a specific program (P1) to put data from A together with data from B, can be done in the SynWeb. In that case, the knowledge is going to reside *within* the program P1.[2]
The one thing that the semweb promises that the non-semweb can't is the "miracle" applications : where A and B produce data without any knowledge of, or deliberate co-ordination with, each other, and a user of program P2, which is a generic semweb joiner without any special knowledge of A or B, finds that the two forms of data are such an exact fit that they can usefully be combined.
I guess the degree to which you believe in the semweb promise is the degree to which you think that such miracle situations will occur in real life. Personally, I think that the hard part is understanding the data from A and B sufficiently well to see if and when they can be combined at all.
Anyone who can do that can probably write a P1, containing that insight. Manipulating the relevant XML, especially with today's XML libraries, isn't so hard. And I think the SynWeb will see yet more powerful syntax processing and querying tools.[3]
The semweb scenario presupposes users who can't write such a quick custom script to combine A and B, but can understand the data (and the schemas) well enough to notice and formulate (in some sort of query language) sensible joins.
I may be wrong, and I'm always open to counter-evidence, but I still can't think of an example where this has actually taken place (ie. two datasets have been usefully joined by a program which didn't explicitly know about these two data-sets.) Any suggestions?[4]
Notes
[1] Sure you can use something like RDF as a representation format of data for a specific application for one set of users. But in this case the URI isn't actually buying you anything over any other sort of locally produced UID. So the differentiating feature of the semweb isn't actually being used.
[2]
In the comments : [quote]And writing scrapers is reasonably easy to do. I think this has got a lot of potential. There’s more work to be done on the software, but to me it is the best attempt at doing useful RDF that I have seen so far.[/quote]
Of course it's the best attempt at doing anything useful.
But scrapers are the living embodyment of the SynWeb.
Scrapers are the avatars of the theory that programs, not URIs, are what give meaning to data. They're stocks of rival knowledge about how to interpret it.
They're what the SemWeb wants to dispense with. Or rather, would be dispensing with if things were going its way. Instead, the proliferation of scrapers is a strong hint that it's not working out.
[3] RDBMS analogies with the semweb are wrong. The RDBMS is basically a powerful SynWeb tool. Meaning is relative to the applications. The design of a database is typically internal to a project or organization, and meaning derives from this context. To the extent SPARQL is just a good graph-shaped database it might also be a good SynWeb tool.
[4] I think some people have already mentioned the capability of adding data from other ontologies as a passanger on RSS 1.0 feeds, but unless the feed-consumer is doing something interesting with this data, without knowing about it, it still isn't doing anything that a P1-style program in the SynWeb couldn't do.
October 22, 2005
Multi-applications ...
Scribe asks:
If it has emerged and evolved out of a varying set of applications, what does this imply about its suitability for future applications? Especially if all those applications are from 1 person's needs. Will this ad-hoc approach prevent it from being adapted, as well as adopted?
Hmmm. What would you say about a species which seemed to survive in a varying set of environments. What does this imply about its suitability for future environments? :-)
If it has emerged and evolved out of a varying set of applications, what does this imply about its suitability for future applications? Especially if all those applications are from 1 person's needs. Will this ad-hoc approach prevent it from being adapted, as well as adopted?
Hmmm. What would you say about a species which seemed to survive in a varying set of environments. What does this imply about its suitability for future environments? :-)
October 21, 2005
Search Engines as platforms
October 20, 2005
Cringely on Apple
Cringely has been predicting Apple's move into video for ages.
Here's his take on the video iPod story.
Here's his take on the video iPod story.
But it isn't enough to shake the very foundations of network TV and bring Uncle Miltie back to life. And that's the point. Five TV shows are an EXPERIMENT, not a business. The experiment going on here is all on behalf of the major movie studios, the very outfits that haven't yet signed on to distribute their movies through iTunes. The studios want to see how the market accepts these TV series distributed in this format, whether the ability to download the shows has a material impact on their broadcast viewership (ratings), and most especially whether we see a surge of pirated copies of "Lost" - copies that can be traced back to iTunes distribution.
Scribe is sceptical
Scribe doesn't buy the OPML cheerleading yet.
I don't know if 2006 will be the "year" of OPML. But I'm certainly betting on OPML to trounce OML, XOXO etc. And to drive a great many new applications.
A couple of reasons :
First. I downloaded and looked at Taskable (http://www.taskable.com/). I haven't found a use for it myself, but it is kind of intriguing.
Like RSS it "bends" internet space in a new way. When I started to see what was going on with blogs and syndication I called it the "flow internet" : a sort of alternative web, based on fixed people and mobile information. (Rather than fixed information and mobile "surfers")
It just kind of felt different.
This Taskable thing is the same. The information feels like it has a new "shape".
And it's a different shape from syndication. That's why I don't think RSS will simply expand to include the same applications.
Of course, the tree vs. list thing is part of it. But it's also which bits are dynamic and which bits fixed. Unlike an RSS feed, the data is not, itself, sequenced in time. It's permanent. But it can change over time, as the host updates it.
Secondly, part of Winer's genius is that he can recognise useful (if mundane) applications for his stuff; unlike his opponents who normally start with an aesthetic point to make : "want to do outlines in XML? here's how to do it properly".
Dave's OPML strategy, in contrast, is a sequence of little applications. First OPML as native format for Radio Userland. Then as a format for keeping your blogroll. And your subscription feeds. (If you were using Radio) Then as a directory of favourite music. Then, later, as a directory of podcasts.
Then, as the native format for OPML-the-editor. And in the process, becoming part of the organizing principle behind Scripting News.
In each case, people have been working with the format, getting used to it. I don't see XOXO woven into people's applications the same way.
The recent TechCrunch story was the real bombshell. Suddenly Dave's putting a subscribed-to outline, publicly on his site for everyone to see. It inspires a frenzy of activity as blog software and aggregator authors rush to support this.
Until then, OPML was largely private. Something you used for your notes, or to produce HTML. Now it's become a public language for communicating and people are going to be looking for new applications.
A little optimistic, I feel.
I don't know if 2006 will be the "year" of OPML. But I'm certainly betting on OPML to trounce OML, XOXO etc. And to drive a great many new applications.
A couple of reasons :
First. I downloaded and looked at Taskable (http://www.taskable.com/). I haven't found a use for it myself, but it is kind of intriguing.
Like RSS it "bends" internet space in a new way. When I started to see what was going on with blogs and syndication I called it the "flow internet" : a sort of alternative web, based on fixed people and mobile information. (Rather than fixed information and mobile "surfers")
It just kind of felt different.
This Taskable thing is the same. The information feels like it has a new "shape".
And it's a different shape from syndication. That's why I don't think RSS will simply expand to include the same applications.
Of course, the tree vs. list thing is part of it. But it's also which bits are dynamic and which bits fixed. Unlike an RSS feed, the data is not, itself, sequenced in time. It's permanent. But it can change over time, as the host updates it.
Secondly, part of Winer's genius is that he can recognise useful (if mundane) applications for his stuff; unlike his opponents who normally start with an aesthetic point to make : "want to do outlines in XML? here's how to do it properly".
Dave's OPML strategy, in contrast, is a sequence of little applications. First OPML as native format for Radio Userland. Then as a format for keeping your blogroll. And your subscription feeds. (If you were using Radio) Then as a directory of favourite music. Then, later, as a directory of podcasts.
Then, as the native format for OPML-the-editor. And in the process, becoming part of the organizing principle behind Scripting News.
In each case, people have been working with the format, getting used to it. I don't see XOXO woven into people's applications the same way.
The recent TechCrunch story was the real bombshell. Suddenly Dave's putting a subscribed-to outline, publicly on his site for everyone to see. It inspires a frenzy of activity as blog software and aggregator authors rush to support this.
Until then, OPML was largely private. Something you used for your notes, or to produce HTML. Now it's become a public language for communicating and people are going to be looking for new applications.
Dominate Design
Ben Hyde on Dominate Design
Hadn't come across this term before. But it might be useful.
Dominate design is a term of art among the folks who think about innovation. Dominate designs emerge in design spaces as innovators progressively “mine-out” the options in the design space. Once the dominate designs emerge it becomes possible for complementary activities to gather around them - i.e. they create new design spaces. I like the term because it avoids calling these the best designs. The emergence of dominate designs is extremely contextual and path dependent. Owning the dominate design, being the early into that part of the design space, and encouraging the emergance of the compilmentary stuff is all part and parcel of the gold rush in and around one of these design spaces. Careful though. It is rare tha a single dominate design emerges from a design space; more typically a bloom of designs emerges. How skewed the user’s adoption of these designs turns out varies. There are, for example, a handful of dominate designs for operating systems. Typical power-law stuff.
Hadn't come across this term before. But it might be useful.
October 19, 2005
John Robb's Weblog: Platform wars in the Auto Industry
John Robb sees a platform war between hybrid and non-hybrid engines in the car industry
Here's where it gets interesting. They are starting to think in terms of platforms and ecosystems (although they are very wrong in thinking that this is as simple as a betamax and VHS format war, it has broader implications since it is a platform war)
Based on the quote : Larry Burns, GM vice president of research and development, says the biggest lesson from that war [VHS vs. Betamax] was that sitting on the sidelines and relinquishing control would be risky.
Here's where it gets interesting. They are starting to think in terms of platforms and ecosystems (although they are very wrong in thinking that this is as simple as a betamax and VHS format war, it has broader implications since it is a platform war)
Based on the quote : Larry Burns, GM vice president of research and development, says the biggest lesson from that war [VHS vs. Betamax] was that sitting on the sidelines and relinquishing control would be risky.
Skype privacy
Will Skype's aquisition by EBay make it more likely to be wiretapped by the US government?
October 18, 2005
Cristian Vidmar: OPML reading lists scenarios
More stuff happening in the OPML world. Cristian Vidmar: OPML reading lists scenarios
October 16, 2005
Yahoo Adds Its Name to AOL's Full Dance Card
So what's all the interest in buying AOL?
Yahoo Adds Its Name to AOL's Full Dance Card
Clearly getting all the customers. But who has the most interesting strategic vision for AOL?
Can't just be because they bought Weblogs Inc., right?
Yahoo Adds Its Name to AOL's Full Dance Card
Clearly getting all the customers. But who has the most interesting strategic vision for AOL?
Can't just be because they bought Weblogs Inc., right?
October 15, 2005
Nings supports commercial developers
Ning blog :
Sensible attitude from Ning.
Hmm. "healthy capitalism"? Well, putting programs to work is about as healthy as it can get, I suppose.
Via Social Software Intellectuals
We want to encourage this type of healthy capitalism on the Ning Playground. As a Beta Developer, you can do a number of things today to start lining your pockets with revenue from your app
Sensible attitude from Ning.
Hmm. "healthy capitalism"? Well, putting programs to work is about as healthy as it can get, I suppose.
Via Social Software Intellectuals
October 12, 2005
Bubblegeneration on Flock
Now, let's go back to GM for a sec. What happened? Well, the rise of more efficient Japanese production techniques eventually (massively) outwieghed any scale/scope economies GM realized.
In my analogy, this is basically like saying that specializers - Technorati, YouTube, etc - innovate more and faster. This is the big problem I see for Flock. Sure, integration offers huge benefits. But specializers are often able to, well, specialize, and offer consumers a hugely more attractive value prop.If this is the case, Flock is going to find driving mass-market adoption difficult.
Another point that's been bugging me is this. Disruptive techs are usually worse on some dimensions/features/etc and radically better on others. I'm not sure I see this in Flock - especially not the worse part; it seems more incremental to me. If it's incremental, can it really offer a strong enough value prop to entice people to switch?
Bubblegeneration - Evil Corporations Only
Yeah, right.
Steven Sinofsky:
Office beta coming in November | Tech News on ZDNet
Generally speaking, we've always had the point of view that the value comes with the tools themselves. The format is a way of representing the features in the product and a way of maintaining the reliability and the robustness.
Office beta coming in November | Tech News on ZDNet
The OPML Vision
Dave Winer says :
Is the idea sexy enough? Right now, I'm not sure I feel that, intuitively. But let's see ...
Can you see where this is going? The step after this is to have the stories emitted in OPML, then you could browse a blog, as if it were a single document, in an OPML browser. Sure there aren't many OPML browsers in 2005, just like there weren't many RSS aggregators in 1999, or podcasting clients in 2004. Just takes one to get the ball rolling, if the idea is sexy enough.
Is the idea sexy enough? Right now, I'm not sure I feel that, intuitively. But let's see ...
Desktop Design Tools
In comments to an earlier post scribe says :
Good point. And I wonder what effect Results Oriented U.I. will have. More design by choosing templates.
Similarly, what fate off-line web design tools such as Dreamweaver in a world where functionality is (finally) more important than design? If blogs and RSS are the in-things for the last couple of years, and yet neither requires any substantial amount of design (either due to pre-selected templates in the case of many blogs, or a concentration on presenting content in both cases), where does the demand for further progress in design packages come from? Furthermore, the more flexible nature of web browsers - the ability to edit HTML and CSS in real time a la, for example, GreaseMonkey - makes web-based web-editing much more likely, IMHO.
Good point. And I wonder what effect Results Oriented U.I. will have. More design by choosing templates.
Meeting Over a Cup of Java
Robert Cringely, has a good discussion of the Sun / Google deal and the intensifying struggle between Google and Microsoft.
Definitely read it. But here are the highlights.
MS view their newly friendly relations with Sun as their access to the standards communities, where Sun are big players.
MS knows it has to give up on
Instead, MS want to move towards renting access to light-applications, hooked into back-end services. So expect, for example, the new Office and newer versions of Windows to depend more heavily on MSN.
This, getting out of big, stand-alone desktop applications is also their response to the challenge from free-software. Source-code is less important, servers and services more so.
MS think Google want to compete in the same game, using OpenOffice as their front-end; but in fact Google will want to truly wrap and commoditise the desktop OS and client by going full AJAX and doing everything in the browser.
Sun will sell the back-end servers for Google.
Beyond this, Cringely, modestly claims he can't see.
Maybe ...
Here's one way it might go. Amazon have Z-Shops. EBay exist to allow one customer / user to sell to another.
Google are one of the "infrastructure giants" of the internet. Do they really want to be selling services direct to the users? Or even reselling Sun servers to users? What they really want to be doing (I suggest) is helping wire-up other people who sell services to each other.
Of course, that's why they're in Grid computing, providing WiFi, and encouraging other people to mash-up their map data. AdSense monetizes the relationship between content providers and content readers. Google will want to monetize application builders selling to application users.
And anything that helps application builders, helps Google.
Which means that if Ning turns out to be at all succesful, I suspect Google would be very interested.
BTW : I notice Ning now seems to have a cool biodiesel finder app.
Definitely read it. But here are the highlights.
MS view their newly friendly relations with Sun as their access to the standards communities, where Sun are big players.
MS knows it has to give up on
- a) locking users into proprietory formats, and
- b) long term roll-outs of complex upgrades of stand-alone, desktop applications
Instead, MS want to move towards renting access to light-applications, hooked into back-end services. So expect, for example, the new Office and newer versions of Windows to depend more heavily on MSN.
This, getting out of big, stand-alone desktop applications is also their response to the challenge from free-software. Source-code is less important, servers and services more so.
MS think Google want to compete in the same game, using OpenOffice as their front-end; but in fact Google will want to truly wrap and commoditise the desktop OS and client by going full AJAX and doing everything in the browser.
Sun will sell the back-end servers for Google.
Beyond this, Cringely, modestly claims he can't see.
Maybe ...
Here's one way it might go. Amazon have Z-Shops. EBay exist to allow one customer / user to sell to another.
Google are one of the "infrastructure giants" of the internet. Do they really want to be selling services direct to the users? Or even reselling Sun servers to users? What they really want to be doing (I suggest) is helping wire-up other people who sell services to each other.
Of course, that's why they're in Grid computing, providing WiFi, and encouraging other people to mash-up their map data. AdSense monetizes the relationship between content providers and content readers. Google will want to monetize application builders selling to application users.
And anything that helps application builders, helps Google.
Which means that if Ning turns out to be at all succesful, I suspect Google would be very interested.
BTW : I notice Ning now seems to have a cool biodiesel finder app.
October 11, 2005
Les Orchard on the Kerfluffle over OPML. Everyone wonders whether OPML vs. its rivals is going to be a rehash of the RSS wars.
I might as well come clean to readers of this blog and say that I'm a huge Dave Winer fan.
Here's what I said in Les's comments :
I've been writing several comments on this topic on different blogs, but I think the subject ought to be consolidated here. Although I'm in a rush so consider this the first of several musings.
The first point is that I definitely bet on OPML to win any coming showdown with rivals such as OML or XOXO. That's partly Winer's vision and leadership (what he's call "philosophy"). And the above point that it's a real application for him, rather than a mere intellectual exercise.
It's also because Winer already has attention, of course.
And it's partly because OPML is already getting locked-in by it's connections with existing tools. OPML, the editor, is a free tool for doing what Winer wants people to do with the format. Blogroll management tools already use OPML. As do RSS subscription and podcast directories. And while I take Les's point that blogrolls are essentially already using XOXO, I'm not sure that is going to be the case for long.
Over at Danny Ayers's blog I've been arguing that the blogroll is actually in conflict with FOAF, and that shifting to OPML is going to be part of that.
(Actually, I said a lot more over there that I need to come back to in a future post.)
I might as well come clean to readers of this blog and say that I'm a huge Dave Winer fan.
Here's what I said in Les's comments :
The reason Dave Winer and OPML will win this, is because Winer really wants shared outlining on the internet. And he knows “why” he wants it. He has a vision, and a passion for it. He knows what he wants to do with it. He knows how to make interesting applications with like-minded collaborators.
You can come up with a “better” format than OPML. You might be able to knock off better code overnight. But you do it for a “lark” or for some principle of “doing it properly”.
Winer doesn’t care if its “crappy”. He just has a drive to make something happen, and OPML is the simplest thing that can possibly work to do that.
I think that’s exactly the right thing to bet on.
I've been writing several comments on this topic on different blogs, but I think the subject ought to be consolidated here. Although I'm in a rush so consider this the first of several musings.
The first point is that I definitely bet on OPML to win any coming showdown with rivals such as OML or XOXO. That's partly Winer's vision and leadership (what he's call "philosophy"). And the above point that it's a real application for him, rather than a mere intellectual exercise.
It's also because Winer already has attention, of course.
And it's partly because OPML is already getting locked-in by it's connections with existing tools. OPML, the editor, is a free tool for doing what Winer wants people to do with the format. Blogroll management tools already use OPML. As do RSS subscription and podcast directories. And while I take Les's point that blogrolls are essentially already using XOXO, I'm not sure that is going to be the case for long.
Over at Danny Ayers's blog I've been arguing that the blogroll is actually in conflict with FOAF, and that shifting to OPML is going to be part of that.
(Actually, I said a lot more over there that I need to come back to in a future post.)
October 10, 2005
Tim Bray thinks most applications are moving to the web-as-platform. However there are exceptions
From right now in 2005, I see three families of desktop apps that are here for the long haul: First the browser itself, including variations like news readers and music finders, whether P2P or centralized. Second, realtime human-to-human communication, spanning the spectrum from text to voice to video. Third, content creation: PhotoShop, Excel, DreamWeaver, and whatever we’ll need for what we’re creating tomorrow.
October 05, 2005
Ning
In theory, Ning could be a killer.
We've been talking about the web-as-a-platform for ten years. And yet we've been building web applications pretty much the same way since then. It's still hard.
What normally happens is there's a server which delivers static web-pages or calls programs that are written in a more or less traditional programming language.
The only improvements on this model, from the programmer's perspective, have been these : templating systems like Coldfusion and PHP which allow calls to functions and bits of code to be embedded directly in HTML templates; and object publishing systems, like Zope, have allowed particular HTTP requests to map directly to object methods within the program. Zope also allows development through the browser.
Beyond this, everything else is handled as libraries, within a fairly traditional programming context. And built with fairly standard tools. It's still hard.
And yet the web-as-platform gets ever more complex : applications ping each other, pipe RSS feeds around, crawl and search each other's databases etc. What's needed is a far higher level abstraction over the web.
Ning looks like it's moving in several interesting directions :
In fact, put these together and you see that Ning is really a kind if social software development platform. All developers build in the same space. All developers can see each other's work and learn from it. These are the lessons of free-software integrated into the web.
I wonder how other platforms for developers can learn from this.
Developers have social software, of course : Source code search, source code repositories, bug trackers etc.
It will be interesting to see if these can all be integrated into an IDE that has a shared platform at its heart, with view-source of other applications as standard.
We've been talking about the web-as-a-platform for ten years. And yet we've been building web applications pretty much the same way since then. It's still hard.
What normally happens is there's a server which delivers static web-pages or calls programs that are written in a more or less traditional programming language.
The only improvements on this model, from the programmer's perspective, have been these : templating systems like Coldfusion and PHP which allow calls to functions and bits of code to be embedded directly in HTML templates; and object publishing systems, like Zope, have allowed particular HTTP requests to map directly to object methods within the program. Zope also allows development through the browser.
Beyond this, everything else is handled as libraries, within a fairly traditional programming context. And built with fairly standard tools. It's still hard.
And yet the web-as-platform gets ever more complex : applications ping each other, pipe RSS feeds around, crawl and search each other's databases etc. What's needed is a far higher level abstraction over the web.
Ning looks like it's moving in several interesting directions :
- You build your applications on top of the application server (rather than on your desktop and then having to plug it in to the server)
- View Source
In fact, put these together and you see that Ning is really a kind if social software development platform. All developers build in the same space. All developers can see each other's work and learn from it. These are the lessons of free-software integrated into the web.
I wonder how other platforms for developers can learn from this.
Developers have social software, of course : Source code search, source code repositories, bug trackers etc.
It will be interesting to see if these can all be integrated into an IDE that has a shared platform at its heart, with view-source of other applications as standard.
Jorn Barger cynical about the Skype / EBay deal.
Is it possible that eBay's killer-app for Skype
is video telemarketing via vSkype?
Robot Wisdom auxiliary: vBay = vSkype eBay
Is it possible that eBay's killer-app for Skype
is video telemarketing via vSkype?
Robot Wisdom auxiliary: vBay = vSkype eBay
John Battelle : the push is on to get more Toolbars downloaded. And now, I see why Google is doing this Sun deal.
John Battelle's Searchblog: Google-Sun - The Toolbar, Ay, There's the Rub
John Battelle's Searchblog: Google-Sun - The Toolbar, Ay, There's the Rub
October 04, 2005
OK, it's a good day to soft-launch (on impulse) a "Platform Wars" blog.
Google and Sun signed a deal
Sort of reminds you of the old IBM / Apple deal from the early 90s, innit?
So what's it about?
Good for Sun's image. Who were they again?
Google's strategy is apparently the quintessential "network is the computer" company. All the new pseudopods being thrown out are web-is-the-platform.
OpenOffice, Google have a chance to kick Microsoft where it hurts. This is a declaration of intent.
Although it's not entirely clear what Google can do for OpenOffice. Will they advertise it? Google don't advertise. Will they turn it into a web-app? Surely the future of web-apps is small and specialized. Think 37 Signals not all singing and dancing bloatware. Will they find new ways to web-enable it and turn it into a new sort of client? I don't see it. Although if MS are reorganizing the new Office as a more web-enabled and integrated package (and remember Ray Ozzie is taking over), then maybe Google and Sun are setting up OpenOffice as a comparable alternative.
Hmmm ...
Some interesting comment from Dana Gardner :
And TechDirt says :
Google and Sun signed a deal
Sort of reminds you of the old IBM / Apple deal from the early 90s, innit?
So what's it about?
Good for Sun's image. Who were they again?
Google's strategy is apparently the quintessential "network is the computer" company. All the new pseudopods being thrown out are web-is-the-platform.
OpenOffice, Google have a chance to kick Microsoft where it hurts. This is a declaration of intent.
Although it's not entirely clear what Google can do for OpenOffice. Will they advertise it? Google don't advertise. Will they turn it into a web-app? Surely the future of web-apps is small and specialized. Think 37 Signals not all singing and dancing bloatware. Will they find new ways to web-enable it and turn it into a new sort of client? I don't see it. Although if MS are reorganizing the new Office as a more web-enabled and integrated package (and remember Ray Ozzie is taking over), then maybe Google and Sun are setting up OpenOffice as a comparable alternative.
Hmmm ...
Some interesting comment from Dana Gardner :
It is no longer remote of feasibility nor far-off in time and space that low-cost, high-quality, high-reliability baseline workgroup productivity applications and voice and data communications together as subscription services become available. And just in time so that CFOs can do a thorough cost-benefit analysis against next year's Vista-Office 12 "connected systems" approach rollout.
So what do the vague announcements today about the Google-Sun deal-in-motion mean? Sun gets to showcase its present and future data center and services delivery platform grid efficiencies at the premier ISV: Google. Java Runtime Environment on the desktop gets a life-sustaining shot of vitamin B-12, while OpenOffice-StarOffice might well become the R&D replacement and speed-to-market turbo-charge that Google needs to leap out front in the race to redefine the client computing-as-service experience. Make that mission-critical experience.
Now, who needs to worry most about Sun and Google making happy-face? I say it's the voice and data networks providers, the Verizons, Sprints, SBCs, BTs, MCIs, BellSouths, and France Telecoms. Because if Sun+Google=Voice and Data Efficiencies as a service stream, aka Webtone, par excellence, on a global scale, then who are you gonna call when you need business services?
And TechDirt says :
Google's got something up its sleeve. But when that announcement comes, don't expect Sun to get much mention.
Subscribe to:
Posts (Atom)
