Joel on the "Marimba Phenomenon"

Does ship-early-and-often really work for a huge company doing massive PR pushes that's going to get millions of people checking out their early release?

Joel on Software

Boydian strategy applied to business

Danny Ayers : Microsoft Unplugged

They’ve one or two high-profile setbacks recently, so this is probably around Plan C. I’m sorry, but I get the distinct impression that they’re still clinging to the sinking ship of Microsoft as Platform, and this looks like an act of total desperation following the realisation that the Web wasn’t under their control.

If this is their 5-year plan, then that’s also probably their remaining lifespan as one of the giants in the industry.

Danny Ayers, Raw Blog : � Microsoft Unplugged

O'Reilly quotes Ozzie

My favorite line, from Ray Ozzie: "Some say that the internet itself is the platform, and in many ways that's true. The internet has always been described as a network of networks, and it's now becoming a platform of platforms, as every web site is potentially a platform."

O'Reilly Radar > Live Software

Bubblegeneration on Ning

Umair Haque has problems with my suggestions for Ning :

Not a bad idea, but there are a few problems with this strategy.

1) The market is not huge

2) There are many (many) substitutes, most of which are open-source (=free)

3) Most of the end-user markets are winner-take-all markets; ie, there's not a huge gap for a Metafilter, in, say, finance - Mefi's already got it covered.

4) But the biggie is really that Ning is a layer commoditizer. Ning's bet is esentially the peer production/cheap coordination bet - that the core atomizes, and so value shifts to the edges of the value chain, and Ning will be able to grab a share (somehow). Positioning as middleware contradicts these economics.

OK, some good points. But I think they're wrong.

1) Cast your mind back to 1995 and imagine someone assessing the market for blog-hosting who says : "this won't be important, the number of journalists is tiny."

The existance of a new price-point for publishing created a much bigger market because a larger number of people got involved. Remember that my post was a response to the question "what (in web 2.0) is disruptive?" and I argued we should stick to Christensen's notion. In these cases "disruptive innovations" make something available for the first time, to people outside the traditional market.

Of course, building little web-applications is probably not as large a market as building little web-based opinion columns, but the size is yet to be tested.

Here are some people who might be building applications if the price was right :

• Anyone who uses a spreadsheet. These were once specialist tools for accountants and financial analysts. Now spreadsheets are probably the most widely produced "applications" written.



• Anyone who has an idea for a "mash-up" of two pieces of data from other sites. Mash-ups now range from custom Greasemonkey scripts to Ning apps. to SPARQL queries on RDF databases to cutting and pasting AdSense ads or the Iraq Body Count box into their blog's gutter. People understand this principle, even when they don't understand how to make it work. Easy, stereotypical application development would help these people.



• Anyone who wants "customized" applications / services on their site. At the moment, you can use out of the box blogging software, wikis, discussion forums etc. Or you can pay someone to produce bespoke applications. There's still a large gulf in between. The small business who loves the existing out-of-the-box customer feedback form, but would just like to add one more field which allowed their customer to add an invoice number. Suddenly the small developer needs to charge another 10,000 dollars for another week's work. What if that sort of customization could be brought down to an hour's extra work in a higher-level configuration language?

2) Against free software. There are two costs to developing applications : one is the cost of paying Microsoft (or Sun or IBM) for the tools. The other is the time to understand the tools and actually develop the application. Of the two, the second is usually more serious. And free software doesn't offer any improvement here. There are libraries and toolkits and languages available for developers, but they work at much the same level as the commercial ones. And often the commercial tools are slicker and build the product with less friction than the free ones.

What I'm hoping for from Ning (or similar web-development platform) is something that can produce an order of magnitude efficiency for producing "stereotypical" applications. Free-software is not offering those savings in development time.

3) Once again, I beg to differ. One of the strange aspects of the new web is that lots of old ideas are being re-invented. Is vbulletin somehow less susceptible to competition by something better than Hotmail was to GMail?

4) Good point, in the sense that it looks at first glance as if Ning is only aimed at the very edge of the network, the individual user. What I was suggesting was that Ning didn't exactly drop this emphasis, but supplemented it by looking at the nearly-edge; created a tool for small ISVs and web-development agencies to more cheaply build customized, stereotypical applications for their customers. This is certainly pushing things further out than the current tools do, but not looking to final "end users".

Postscript on names : Oh, and it's not like web 1.0 names were all that. Seth Godin (and others in marketing) have the opinion that it's more important for the name to be unique and findable. "Generic" names are hated. del.icio.us, I can't help feeling succeeded despite the name. Or maybe it's a kind of "fuck you, we're impossible to remember but we don't care" name. I don't use it, anyway.

Ruby vs. Python : Community friendliness?

Ruby and Python are two fairly evenly matched languages in their technical capacity. But Ruby is getting a lot of people excited, while Python (sniff) is lagging behind. This is partly to do with Ruby on Rails, a very easy-to-use and pretty, web-application platform. Python's equivalent major web-platform, Zope, was lauded as powerful, but is pretty heavy and bureacratic.

But might the personalities of the communities also play a role? MF Bliki: RubyPeople

Innovation, Technology and the Nature of Prosperity | Platform Wars

So someone else got the domain name. I wonder what he's going to do with it.

Common Craft - Social Design for the Web: Project Platform Wars

I'm in no sense a Mac fanatic. I've never owned a piece of Apple hardware or software and don't intend to. But I think this is a sad, if instructive, story :

The platform issue got escalated, as it had the potential to cause major problems. As it turned out- the answer was simple. Our project leader simply said that the company uses Microsoft products and that means that all diagrams, wireframes, etc. need to be done in Visio because of future hand-off to enterprise teams.

Common Craft - Social Design for the Web: Project Platform Wars

Two species - Mac and Windows - contested a space. The Mac succesfully invaded, proved more succesful, but was then stopped by a bureaucratic decree.

Robert Axelrod has a good discussion of what makes for a succesful species : initial viability, robustness, stability. Initial viability is the capacity to thrive when surrounded by other species. The Mac clearly demonstrated this. Either it was inherantly more compatible with the Windows protocols and software or, it encouraged smarter users who were able to make compatibility work.

Windows reinvaded the space through neither inherant nor externalized virtues, but through the shere momentum of numbers.

NamePros.Com - FAQ: Adsense Revenue Sharing

Interesting. Here's a discussion board with Adsense Revenue Sharing.

Seems to fit Umair Haque's intuition (which I was rather sceptical about here) that there was room for pulverising payment for content even smaller.

Ross Mayfield on MS

Ross Mayfield on Microsoft's expected announcement of a move into selling more services delivered over the web.

Ross Mayfield's Weblog: Turn on a Dime

Last days of AutoCAD

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.

Scobleizer - the future of Web businesses

Scobleizer Silicon Valley got my attention: the future of Web businesses

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?

del.icio.us didn't scale either :-(

The RSS blog says :

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. :-)

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.

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).

The Bottoms Up RDF Tutorial

Burningbird gives one of the best RDF tutorials I've yet to see.

What did Google disrupt?

Google disrupted online advertising

Is Web 2.0 killing the Semantic Web?

Is Web 2.0 killing the Semantic Web?

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.

Bubblegeneration on web 2.0

Umair Haque has a couple of interesting posts on Web 2.0

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?