I've been trying to come up with a concise way of saying this, the Web 2.0 model served its purpose, it got content management into every nook and cranny of Internet life. But at a cost.
We gave up control over the experience to companies whose incentives and interests conflict with ours. A necessary bargain when running a server is so complex and expensive.
New models for communication can develop, independent of the limits and needs of companies that run the Web 2.0 servers. I don't think Web 2.0 will go away, but a new net can take its place beside it. And that's all that's needed to boot up a new layer.
Access journalism is why you hear flattering personal stories about rich people, and more realistic stories about people with less money or influence. Reporters need access to them, and if they don't like what you write, they won't talk with you, or no access. It sometimes applies to whole countries. If China doesn't like what you write about them, they'll kick your reporters out of the country.
Journalists don't generally write about access journalism. It's the environment, the context. You don't talk about it because it's everything and everywhere.
So it's unusual for the NY Times to run a piece about it.
The story is about Bloomberg reporters working on government corruption in China. "Mr. Winkler defended his decision, comparing it to the self-censorship by foreign news bureaus trying to preserve their ability to report inside Nazi-era Germany, according to Bloomberg employees familiar with the discussion."
Winkler is the Bloomberg editor who killed the China corruption story.
It's only natural as our economies integrate, so do our political systems. This evening-out is probably the larger force behind the move of the US to become a surveillance state. If our trading partners do it, the incentive is there for us to.
Remarkable story, totally worth reading.
Interesting thread on Twitter last night, I wanted to capture it here before it scrolls off.
I posted a note about how I was studying John Gruber's Markdown spec, and said I liked it. It reminds me of the RSS 2.0 spec. What I meant: It tends to answer questions I have, when I have them. It was written for someone who's implementing Markdown, not someone who's on a mail list debating it. Big difference in approach.
He explained: "I think it is easy to hide unclear thinking and bad ideas behind the opaque lifeless writing style of IETF-style specifications."
I have to admit I don't know very much about the way IETF does things, except from my experience watching the Atom group do their work. I have implemented Atom in River2 and River3, but it wasn't with the spec. I did it as I always do these things, with a set of sample files from popular sites. I made sure my aggregator could handle them. That was enough. If there had been an English-language spec for Atom, I probably would have used it. But I didn't need it to get a compatible implementation. To me that's what all this stuff is about.
I was glad to see Markdown has gained traction, and done so much to help web content developers simplify their work and make web-writing accessible to more people. I'm doing more with Markdown now, making my second approach to it as an implementer.
I do have questions about how it works, and I understand that there's no formal spec, but I also see it widely deployed. In tech there are always tradeoffs. I think this is the case here as well. There must be advantages to formal specs, but there are also advantages to ones that are written for busy developers.
For example, what about line-endings?
Is it "\r", "\n", "\r\n" -- or as I suspect -- any of the above?
Also, if I put a macro on a line by itself, I would like it to get the <p> treatment. But Markdown processors see the left angle bracket and apparently thinks it's HTML, and leaves it alone (which is explained in Gruber's spec). This is causing me some difficulty.
Macros in my world look like this: <%macro%>.
I wonder if there aren't other formats and protocols that use same approach we used for RSS and Markdown? I wonder if there aren't other open technology people who create for busy developers?
The idea of writing specs for "busy developers" started, as far as I know, with the Busy Developer's Guide to SOAP that Jake Savin and I wrote, in 2001. I wrote a blog post explaining the need for it. For the spec itself we have to go to archive.org.