NYT publisher Arthur Sulzberger said the mistake they made was not hiring more programmers sooner. I thought this was noteworthy -- I think the exact opposite is true. I think the Times should have tried to avoid hiring programmers as much as possible. Before they had a lot of programmers it was possible to do deals with them, after the programmers came on, they had yet another set of gatekeepers, who as a side-effect of doing their jobs, kept new ideas from penetrating the Times.

It's the nature of employees to want to do the things outsiders might do for you. And it's not just money it's costing you. People coming from outside your organization are free to think without the encumbrances of insiders. By bringing programmers in, they made sure that new ideas couldn't get in. At a time when there were lots of new ideas springing up all around the Times, rich new activities they could have owned, instead of ceding them to startups like Facebook, Twitter, Stack Exchange and LinkedIn, and thousands of others who quickly built fortunes around the stuff the Times is already so good at producing.

It's too bad, because when the Times was able to wheel and deal something very good happened, RSS. As such an unqualified success, it should have been used as the model for other good things that could have happened, but didn't, because of gatekeeping.

For example, I had a very simple Blackberry river of news for the Times in 2006. This was before it was known widely that mobile was everything (another thing Sulzberger said last night). But it couldn't happen because the Times had its own internal effort to do a mobile app that was, imho, nowhere near as easy, fast or nice as the one I was able to whip up in a weekend because I didn't have the time to make it complicated.

I just wanted something that would let me read the latest news on BART. Mine really worked. I still don't think they have a good simple mobile reader at the NYT. My own opinion of course.

I could have gone to the meetup in Cambridge yesterday, but chose not to because these events are all about creating justification for keeping things as they are, and I am often used as a foil for the evil ideas that are trying to get in to make things work differently. I've been lectured by the best Shorenstein has to offer about why what I'm proposing can never work despite all evidence to the contrary.

Shorentstein has that legacy. It's not my favorite approach. I think news organizations should be in Let a Thousand Flowers Bloom mode, and should see every new application of news as good news for their industry.

This led me to wonder in a fanciful way -- where is the anti-Shorenstein? The un-Shorenstein? In Superman terms, the Bizarro Shorenstein where they do everything exactly the opposite of the way Shorenstein does it? In that meeting the leaders of the news industry would do their share of listening, and new ideas would be welcome and allowed to blossom.

Outliners are an odd kind of productivity app, because they have a dual identity.

This duality introduced confusion in the design of outliners from the very beginning, which for me was during the late 1970s (for Engelbart it was quite a bit earlier).

Casual observers often jump to the conclusion that outliners are a breed of word processor, but that's not necessarily true. My outliners have a bit of filesystem and a bit of a word processor. And because there's only one keyboard and one mouse, this balance can get tricky. You have to choose operations to associate with each gesture.

But we've struck a good balance, imho. I don't think of Fargo as a word processor, like Word or the one in Google Docs, but it is equal to most text editing tasks that a writer such as myself has.

The Finder and Explorer in the Mac/Windows desktop operating systems meet the basic qualification of being an outliner in that:

In other words they have expand/collapse and dragging move. You have control over detail and when you move something in an outliner, everything that's underneath it goes with it.

Fargo has built on the idea of an outline as a collection of documents by coming up with a way of putting an outliner-like "page break" in a the outline structure. If a headline has a type attribute then it's the title of a document, and its sub-heads form the body of the document. In this way it's acting like the Finder, with an important difference, there's no need to open a separate window to edit the contents of a document. Just expand and start editing. And moving items between documents is done with the same dragging move operation that moves a file from one folder to another.

The type attribute is important when rendering, and it will prove important when we use outlines to author Evernote stacks (they call them notebooks) or WordPress blogs, as examples.

Otherwise, in every way, the headlines with the type attributes behave exactly like outliner nodes when you're in the outliner. It's just when you're viewing the content in a non-outliner, they become the documents -- the notes in Evernote and the blog posts in WordPress.

For example, here's a screen shot of the outline I'm working in right now.

I have one post expanded, a short one, so you can see the structure of the outline.

Headlines that have a document icon instead of a wedge are the ones with type attributes. These are the documents.

The entirety of my blog is in a single OPML document stored in Dropbox.

Our CMS software, Trex, understands these conventions, and renders the website appropriately. The RSS feed for the site also keys off these markers.

This idea represents a breakthrough in outlining software, imho. It first appeared in the OPML Editor a couple of years ago, and formed the foundation for the World Outline idea, which is now fully implemented in Fargo and Trex. It's all very loosely-coupled so any outliner that emits OPML can product the content understood by Trex, and Fargo could hook into any CMS or other processor that works this way.

We're working with several other developers on software that exploits this concept, and hope to have something to demo here perhaps as soon as the Evernote conference at the end of the month (fingers crossed).

If you're a developer and you want to see for yourself, here's the OPML file for this site. You can see how it works for yourself. It's got all kinds of scripts and templates that make a real website work, so be prepared!

Questions or comments are welcome.