Go Dave!

I think maybe I should write a book about how you invent and promote standards for fun and profit, because what I'm doing here is exactly what I did when I started blogging, or publishing in XML and then RSS, or started pushing audio blog posts as enclosures in my RSS feeds. You start by putting two things next to each other that you think should work together. Then you shorten the distance, and shorten it again, and keep optimizing until you have something that other people could use. Then you tell them about it, and tell them again, and again and so on until you have a standard.

Jeff Jarvis on GoogTube

Accelerated suicide

Great Steve Yegge post on the importance of Javascript.

This OTM :

This phenomenon will happen in the browser space. I can assure you it will. It's an economic certainty. There's money at play here, lots and LOTS of money; every company in the world wants a cool website. Not just a cool website; they want cool apps. Companies are realizing — glacially, yes, belatedly, yes, but inexorably — that most people with computer access in the world today live inside their browser, and they'd prefer not to leave it.

"Everyone in the world" — that's an awful lot of money at stake.

So as soon as "Scheme on Skis" or "JavaScript on Jets" or whatever comes along, that Rails-like radical simplification of the huge ugly Browser Swamp, the game will change almost overnight.

Kind of makes up for the dumb things he said about Agile a couple of posts ago. ;-)

Hendy commented that Ning isn't open source.

Agreed. I'd like to see an Open Source online web-app development / code-generation / code-management / code-sharing platform. Possibly Trac could evolve in this direction (from a very different starting point.)

I notice that I missed something from the list of improvents (in that previous post I linked) in web development. I said templating-oriented development (eg. PHP), and object publishing systems (eg. Zope) were the only real changes from trying to program web-apps as though they were any other kind of app.

Perhaps I need to add continuations based servers like Seaside. I finally watched these videos and got how cool this is.

Essentially you're allowing the language to hide all the session / interaction management.

Who owns the on-demand customer?

Joel trolling the Ruby community (yes you are, you know it)

Meanwhile, wouldn't the practical thing to do be to write the little bits that need to be fast in C?

The moral of the story is simple. You should see Heavy and YouTube as opposites in strategic error. Heavy doesn't create enough value consistently enough to be able to exert enough pressure to capture a significant share. YouTube, on the other hand, is creating a great deal of value - but also can't exert enough pressure to capture a significant share.

Bubblegeneration Strategy Lab

Trac Hacks is the free-for-all wiki-market where you can find Trac plug-ins and extension macros.

What's one of the most amazing, cool, web-based apps that no-one talks about?

Trac.

It's not flashy, or Ajaxy. But this packs so much useful functionality. Every time I show this to a developer, they drool.

Right now, if I was building a wiki-like application product for use in enterprises, or something to compete with Basecamp, I'd seriously consider starting here rather than with the usual Rails or Turbogears etc. It feels so well thought out that I bet the code is nice. And it's extensible.

Steve Gillmor on Offices

Actually, Google Apps for your Domain is sort of the opposite of what I'm predicting, that SaaS will also be available for local caching. Here the opposite seems to be taking place. Google keep hosting it their end, but let you brand it your way.

Unless, of course, it ends up in a sealed box.

As predicted : construct your river of news in the OPML editor

update : I wonder if he'll find a way to filter out the feedburner ads.

Dion Hinchcliffe : A Timeless Way of Building Software

John Robb compares US rule-set globalization with the real thing.

If the US rule-set is Windows, the new, minimal rule-set is free-software. A lot more open and dynamic (but less user-friendly?)

River of News

Of course, talking about Winer gets links from Dave and more discussion in the comments than most postings. But I don't just do it for the flow. There's something really interesting going on here.

But thanks for all comments, here're my responses (including further development of ideas) :

gardenstate :

of course the money comes from selling weblogs.com. But Winer has no reason to try to mislead people and pretend he has other types of income. He's trying to expand your way of thinking about the economic model of blogs to *include* things like that deal.

danny :

Don't we all take ideas from elsewhere and mix and match them together? I've seen Winer sometimes more, and sometimes less, meticulous about setting the record straight about his influences. He credits them often enough that I think he's not deliberately trying to mislead, although, agreed, I've seen him lazily allow an interviewer call him things like the "inventor of RSS" without correcting that too. (My take is that Dave didn't invent RSS the way Ray Kroc didn't start McDonalds.)

Seems to me, one of the issues is that Dave's been around since the 70s and is copying ideas that were already current then. Today people say "why doesn't Winer credit TBL for the idea of a readable / writable web?" But Dave claims to have been working on outliner-shaped public discussions on buletin-boards in the 80s. If anything he should probably be crediting Plato. Or maybe Engelbart.

In terms of platform building, Winer's modus operandi has always been *incremental*. River of News for NYT and BBC is infinitessimal as a technological invention; it just makes the lives of one group of people (Blackberry users) a tiny bit easier.

But behind the scenes, lots of interesting things are going on : people are getting used to Dave's server becoming an intermediary to their news-reading lives. Pretty soon (I'm betting) there'll be OPML in there. For editing subscriptions, or filters or something else.

So Winer's made strategic links, wiring up various components and actors : big media, himself, mobile devices, an existing user base, OPML Editor, OPML, RSS.

Compare this to Apple's strategy for music. That worked because Apple had all the pieces : iPod as the mobile player, iTunes as the software for buying and recommending, their DRM format, *plus* big music companies willing to go with them. All the parts were there. A music player or service disconnected from this network may have been technically "better" in many ways, but the overall ecosystem from Apple was compelling.

Winer has nothing like the resources of Apple, but look, he's created the same shape of platform : he's got the content, he's got the nice reader, he's got the flow going through his middleware. And now he can start innovating on top of that. Like I say, I'm betting it will start with "edit your subscriptions in an OPML Editor" although Winer's hinting that it might also be "Edit your blog on the Blackberry" too.

Danny has lots of frustrations with Dave, but I think the real issue is that Dave's strategy of minimal incremental improvements plus link-making work with the grain of the web. Whereas the better, comprehensive standards that Danny works with, continuously fail because they are actually against this grain.

What is the shape of the web? Individualistic, opportunistic, one-way links. Anyone on the web can choose, by themselves, to make a link to anyone else. The only required standard is the URL. You don't need two-way co-ordination to make something happen. Yet links are hugely valuable (as Google discovered)

So, what is with the grain of this web? Individualistic link making; the quicker and dirtier the better. Or rather, the more links, the better. And quality is secondary.

Danny wants to make good quality links. He wants a group of smart people to come together to thrash out the right model for a type of data, one which eliminates ugly, funky problems, and is as flexible and generic as possible. Once the model is defined then it should be published and adhered to. How do I find out how to represent my data? I go and find the description of the model, try to read, digest and understand it, and then adhere to it.

Dave is continuously undermining Danny's way of doing things. He won't adhere to the codes for good link quality. Instead he makes valuable links as quickly as possible. (Where valuable means one that has a genuine application or usefulness to someone) Obviously this looks like sabotage from Danny's perspective. It invalidates the hard-work of the people who design the good links, and their attempts to get consensus. And, yes, leads to poorer quality links. (Although not so poor that the culture can't adapt to and live with their deficiencies.)

Winer doesn't do this to be evil. It is a matter of intuition. To me he looks like someone genuinely at home on the web. He lives there. He "washes" there. Of course what he does is with the grain.

dave : I think you're too ad hominem about Danny. I'd like to talk about ideas here.

others : yes (gotta rush)

Guess I'm one of Winer's explainers.

It's only worth getting involved because I think there's actually some ideas here that are worth spelling out and talking about.

Winer has a nice take of his own :

The way technology works, for those who care about such things: Start with a vision you believe in, and keep trying to find ways to show others how powerful it is. Over and over, often for years.

Sounds right to me.

The silliest thing, ever, is people getting all uptight because Dave is "arrogant".

So what?

ZDNet has a good round-up of opinion on why Open source won't doom traditional enterprise software

I'll continue to stick my neck out. Free software + Software-as-a-Service are going to drive today's commercial enterprise models extinct. The only question is how long it will take.

(BTW : yes, free software isn't the same as SaaS, but the two are a good fit, along with eXtreme development.)

Proprietory software is ultimately doomed, because "proprietoriness" is not a feature that customers value or want. At best, it's an inconvenience they're willing to put up with in return for other benefits.

But those benefits will diminish relative to the free / SaaS model.

They'll diminish because :

a) however slow burning, free software is cumulative. If one company providing it dies, the source-code won't go away. It will get resuscitated when the next eager entrepreneur sees a new opportunity to apply it. Free-software is the undead, you can't kill it.

Every generation of competitors based on free-software starts one step closer to the proprietory incumbents.

b) as mentioned earlier software-as-a-service is a better fit, as a business model, for agile, iterative development. And agile development is more effective than giant, product-shaped packages.

The two trends will combine : providers of SaaS won't try to differentiate themselves on the whole software stack. Instead they'll focus on their core application functionality and use free components like LAMP for the rest.

It's the SaaS providers who are already, and will continue to be, at the forefront of free software use. They'll continue to have both the expertise and motivation to engage with the free communities and to contribute back to them. In fact, we'll see most serious free-software worked on in service software companies rather than by total amateurs or product companies.

By succesfully re-using free-software, and through having the freedom to work in a more agile way, SaaS vendors will simply outperform the product makers.

How long will it take the big customers to notice? Hard to tell, but the Free-SaaS combination is classic "disruptive technology". At the moment it still lacks features which satisfy the biggest customers, but it satisfies some, and so is eating its way up through the small and medium sized customers, adapting, evolving and improving itself all the while.

Currently, the main argument against free-SaaS is that software providers don't want to offer it (there's less economic rent to be collected in services than in owning Intellectual Property). That's as may be. But as long as someone can make a profit providing free-SaaS, and is willing to do so, competition and customers will drag the market in this direction.

BTW : it's plausible that the free-SaaS world itself will unbundle into the three types of companies : infrastructure, customer relations and developers. Hence small (dynamically assembled?) clusters of programmers will be paid by a more customer-focused SaaS provider to add a small piece of functionality to an existing free system for existing customers.

BTW 2 : OReilly thinks that mating with SaaS (where the GPL doesn't force people to actually share their changes) will weaken free-software culture. That's possible, but I don't think it's a big deal. In the competition between various ecosystems, the more free will tend to flourish and drive out the less. I may think I can lock-up the veneer of business-logic that I put on top of a LAMP-stack, and charge an economic rent for it.

But my slightly less popular competitors will immedietely scent competitive advantage by opening their developments to each other and the wider community. In fact, as a customer-relations company, I'm probably far more interested in holding on to my customers through good service than locking them in by nefarious tricks.

I'm taking issue with Liam Breck over here.

Breck is smart, and pushing the incredibly cool idea of a wiki-server on a pen-drive. But nevertheless, I'm gonna disagree with his scepticism about web-as-a-platform.

Here's my comment :

Right now, I agree, that web-based simulcra of existing desktop apps are very unlikely to take off.

Why, really, would I want a web-version of Word? If I want something free, then Open Office is as good.

However, apps which are inherently social. and those which deal with online databases, are already native to the web-as-platform.

After GMail, I can't imagine a compelling reason to switch back to non-web-based email client. Nor an offline blog editor etc.

So I think we *will* see a sudden and dramatic shift to web-based applications, particularly in the enterprise, but it's going to be accompanied by a sudden shift to a whole new way of working with new tools. Not a web way to handle Word and Excel files, but a realization that in the age of blogs and WikiCalc we don't actually *need* Word files and Excel spread-sheets 99.99% of the time.

Unlike you, I think this will happen, and I think it's going to switch very fast. It's not something you'll really see coming in long-term rising trends of adoption.

Word benefits from a network effect. When whatever replaces it, replaces it, a sizable chunk of the whole network will have to go almost at the same time. Before this, very little will show up on the radar.

I buy the web 2.5 concept, of course, but my betting is that it's going to be coming via the web-as-a-platform, rather than from desktop / machine-centric software.

So, at some point in the near future, someone will come up with a derivative of Firefox which

a) has its own local database to store as much user data as needed without creating a security holes on your computer,

and

b) can *cache* large javascript applications.

At which point what's the difference between your web 2.5 concept and the mainstream web-as-a-platform service model?

Users will go to a site, implicitly grabbing the application, which will be cached locally, along with the user's data, for offline work. The data will be synced back with the central or cloud servers whenever reconnected. Similarly, the application software will be written as if served centrally, and kept continuously updated, but will be cached locally to minimise network traffic and for offline use.

My feeling is that software-as-a-service is inevitable *as a business model* given two truths about software development :

a) large-scale software development sucks

b) free-software

Trying to specify and build and deploy a large-scale piece of software in one lump (two to three year project) is an incredibly difficult and inefficient way to do it.

It makes far more sense to develop according to iterative Agile / eXtreme methodologies, releasing small new incements of functionality on a regular basis.

The problem with eXtreme or agile development is that it's very difficult to *sell*. Customers want fixed time, cost and functionality negotiated in advance; they don't want an open-ended commitment to funnel money to developers.

How do you reconcile the contradiction : monolithic development sells, monolithic development sucks?

Microsoft used to have an answer, before free-software destroyed it.

SaaS offers another : rent the software, which can be either hosted by the provider or, for convenience and confidentiality, brought inside the organizational firewall.

In practice, installing it in-house is another form of local caching, and is a mere implementational detail for something which at the business level is treated as a service.

In short, this is gonna happen because companies producing SaaS will be more agile and get better quality software written, faster, than those sticking to large scale product development.

In practice, you may have local copies of both the software and your data, but that will be "mere" optimization (and certainly not to be planned "prematurely" :-)

Viral Funpacks!

I've just had an epiphany!

May I present the humble dhtmlxTreeGrid.

Go play with it. It's cute.

I've never seen a TreeGrid before. Or, if I have, I've never really noticed one before. But recently I've been thinking about one of the great challenges of software geometry : "squaring the triangle" (the CS equivalent of the age-old problem of "squaring the circle".)

In other words, managing a world where rectangles (and combinations of rectangles such as tables in a relational database) meet triangles (object hierarchies, outlines and other trees).

When you look at the treegrid, you are looking at the solution of a problem. "Our data has rectangular structure and hierarchical structure. How should we present it to the user?"

Well, in HTML you can have hierarchies :

• a


• b


• 
  
  
  
  • c
  
  
  • 
    
    
    
    • d
    
    
    • e
    
    
    
    
  
  
  • 
    
    
    
    • f
    
    
    
    
  
  
  
  
• g

And you can have tables :

A	B	C
3	2	1

And you can even nest one inside the other :

A	B	C
3	2	a b c d A C 3 1

But no combination of nesting triangles inside rectangles (or vice versa) will actually give you a treegrid. (In fact, it's quite a puzzle to figure out how it works in HTML.)

In the TreeGrid, who is master? At first glance, it looks as though rectangles are. After all, at any level down the hierarchy, the columns are the same. Same width, same type, same format etc. The tree is imprisoned in the grid. Surely, the "hierarchy" is a fake. They're simply keeping some kind of indentation information with each row. A visual trick.

On the other hand, close them all up. You're left with just one node. Are the others really all inside that? Perhaps it's a hierarchy after all, and the columns within each element are simply measured to seem like they line up? Triangle is master and rectangle is illusion?

But what about sorting, and filtering and summ(aris)ing. Surely columns rule there. Or do they? In the example, open them all up and sort by price. Results are constrained within their parent node. But what if you wanted to sum across all subnodes? or filter across all subnodes?

No-one is to be master. Instead triangle and rectangle must subtly interact. They cross-cut, one or the other taking the lead when it comes to particular operations.

The question of how to balance hierarchy with relations goes way beyond interface widgets. Almost certainly the data in your company is both triangular and rectangular. But how does your software treat it? Does it manage to get the right intersections? Or does it force it into one shape, losing the benefits of the other?

What can we learn about beautifully combining rectangles and triangles from looking at the treegrid?

Bonus : Here's another one.