Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 30 2012

September 01 2011

Subscription vs catchment

Recently I was filling out an OSCON feedback survey and arrived at a question that stumped me:

Which of the following industry publications and/or blogs do you read on a regular basis?

Following it was a very long checkbox list, starting with ARS Technica and ACM Queue and ending at ZDNet:

OSCON survey

I started going down the list, answering as best I could, but what I really felt was: "The world doesn't work this way anymore!"

As far as subscriptions go, the main thing I subscribe to these days is Google Alerts and other filters for the topics I care about. Things just float through my alerts, or my Twitter feed, or whatever the catchment du jour is. Subscribing would feel like over-commitment to a single source. If the feedback form had asked "Which of these do you find yourself clicking on most often?" that would have been much closer to reality.

I still have an RSS reader, somewhere around here, but the only two items from the survey list actually in my reader are, I think, Slashdot and O'Reilly Radar. Yet, I read articles from the others all the time. In fact, I'm pretty sure I've read more ZDNet articles than Slashdot articles in the last month, even though I'm "subscribed" to Slashdot but not ZDNet.

As I'm usually not in the advance guard of technology trends, I'm pretty sure I can't be the only person who's basically given up on old-fashioned subscriptions [1]. Is the "subscribe to X" model on its last legs?

Active source loyalty may just not be a thing anymore on the Net. Who evaluates sources as sources now? We're looking more at the cloud of endorsements and references around the sources. This gives us subtle clues as to whether we should go the whole way and click through. More and more, this is true even with publications that have a good reputation and that have spent effort to build that reputation. I like Linux Weekly News (LWN), but I'm not actually going to go to their front page. I'm going to wait until the generalized social waves coursing through the Net bring LWN to me.

TOC Frankfurt 2011 — Being held on Tuesday, Oct. 11, 2011, TOC Frankfurt will feature a full day of cutting-edge keynotes and panel discussions by key figures in the worlds of publishing and technology.

Save 100€ off the regular admission price with code TOC2011OR

The catchment model means that the urgent task, for those trying to get your attention, is to look enough like what your friends and colleagues endorse to fool your filters. (Of course, one way to do that is to enter into partnerships with the filters, or just be the filters. The rest of this parenthetical aside is left as an exercise for the reader.)

In the past, the sources were a destination all on their own. But as the sources become inputs into a larger filtering system, the filters are the next natural target for those seeking influence — or as we prefer to say in the technology field, the next site of innovation. When people are trawling so many sources, it no longer pays to concentrate on sources at all. It makes much more sense to start studying how the trawlers work and how to become part of the filtering infrastructure.

Perhaps this is all obvious. It just struck me because I've filled out similar evaluation forms for years, and only lately has that question felt like it's based on an obsolete model. And that model doesn't just go away: it gets replaced with something else, something in which broad data collection and pattern discernment matter far more than the reputation and branding of any individual source.

Thanks to Andy Oram for his helpful comments on earlier drafts of this post.


[1] Subscriptions on the Internet, that is. I'll still get my paper copy of The New Yorker until they make it illegal to chop down trees to support East Coast intellectual elitism — a day I hope never comes.

Associated photo on home and category pages: email_subscribe by derrickkwa, on Flickr



Related:



August 11 2010

The power of informal contracts

Before releasing elmcity as
an open source project,
it had to be reviewed by a team of Microsoft lawyers. They found no
patentable invention in the code and gave me the green light. Which is
funny in a way, because I'm sure I couldn't ever create a patentable
software invention. I'm just not that talented as a programmer.
Writing code, for me, is mainly a way to explore ideas and illustrate
possibilities. In this case, it's the idea that we can manage data
in a social way by participating in networks of syndicated feeds. And
it's the possibility that a lone developer, modestly capable but
empowered by languages, libraries, tools, and cloud services, can
bring that idea to life.

What is innovative about my project, I claim, is the network-oriented
way of thinking and acting that it embodies and promotes. The
approach is based on a set of principles that we have yet to fully
articulate, never mind teach along with the proverbial three R's.
Almost everybody learns the rules of reading, writing, and
arithmetic. But almost nobody learns the laws that govern the
structure and flow of information in networks, and that enable us to
make effective use of those networks.

We don't need software innovation to solve the problem that the
elmcity project addresses. Our perpetual inability to merge personal
and public calendar data can't be blamed on a lack of standard,
broadly-available software and services. We have all the stuff we
need, and have had for quite some time, and it all interoperates
pretty well. But we haven't internalized why, and how, to
use it in a network-oriented way.

One of the crucial ingredients is something that I'll call the
Principle of Informal Contracts. Here's an example from the early
blogosphere: RSS auto-discovery. It's the mechanism that associates the
pages of a website with a corresponding feed. Back in
2002 a remarkable collaboration brought it
into existence, summarized href="http://diveintomark.org/archives/2002/06/02/importan
t_change_to_the_link_tag">here by Mark Pilgrim who concluded:

Thank you to everyone who has been working on making this come together in the past few days. It has been surprisingly painless and friction-free. Together, we have come up with a new standard that is useful, elegant, forward-thinking, and widely implemented. In 4 day.

Thanks to that consensus, it has ever since been easier to subscribe to
blogs. But what about before then? The blogosphere's feed ecosystem was already
bootstrapped and thriving. RSS, implemented by various feed
publishers and feed readers, was the obvious enabler. But there was also an
informal contract. It went something like this:

My blog publishes a feed at a URL that I will tell you about one way or another. Maybe I'll use an orange icon, maybe I'll use a subscribe link, maybe both, maybe something else. By whatever means, I promise to produce a flow of new items at that URL. The feed itself might be one or another flavor of RSS. Whichever it is, your feed reader can count on finding certain things in a predictable way: a title, a link, a description.

That was enough to get things started in a big way. Here's a more contemporary
example: the contract that's implied by choosing a tag at the beginning of a
conference. It says:

We, the organizers, promise to bind the online resources that we produce for this conference to this tag. And we invite you, the attendees, to do the same. We do not promise to collect all the resources discoverable by means of this tag, dump them into a bucket, and assert authority over (or assume liability for) the contents of the bucket. We just want to be able to find all the stuff, yours and ours, and use it as needed. We want you to be able to do the same. And we think the virtual network routed by that tag can be valuable to everybody.

Members of a certain tribe, which you most likely belong to if you're
reading this, take that contract for granted. For you, the word "camp"
does not connote outdoor recreation, but rather a new kind of
conference that's co-created by the organizers and by the attendees.
One of the organizers' roles is to declare a tag for the conference.
I've watched newcomers to the tribe encounter this practice for the
first time, and then immediately adopt it. So I know the idea is
catching on.

But we haven't yet spelled out the underlying principle of informal
contracts. And we've got to do that, because we're living in a world
where networks of people and data can fruitfully use such contracts. They're easy to
create if you know how and why. Here's the contract for the ecosystem
of calendar feeds that I'm trying to bootstrap:

Anybody who wants to promote a series of public events agrees to publish a feed that transmits certain facts about events in a predictable way: the title, the starting date and time, a link back to the authoritative source. Anybody who wants to curate a view of sets of feeds made available in this way can do so by making a list of them.

Within the project itself, there are some other contracts. Here's one:

To make the lists of feeds that define these curated views, we'll agree to use the delicious social bookmarking service in a particular way. The elmcity service will define the extensible set of delicious accounts used for this purpose. We'll agree that users of those accounts will follow certain practices that define the settings for their instances of the service, and the lists of feeds they trust to flow through their hubs.

That agreement in turn enables another. Because every action in
delicious is a database query that produces an RSS feed, the
acquisition of a new calendar feed by a curator sends a message on a
virtual channel that can be read and reacted to. The service that
reads and reacts, in this case, is FriendFeed. Here's the contract:

Curators can subscribe to a project feed that's aggregated by an instance of the FriendFeed service. Items flowing through its Atom feed are significant events in the life of the project. They include:


  • The posting of a forum message or reply.

  • The posting elsewhere of a tweet, blog item, or other resource bound to the
    project tag.

  • The discovery of a new (and trusted) iCalendar resource by any hub's curator.


  • Like delicious, FriendFeed can support this kind of contract by empowering
    users to define sets of online resources and share them as feeds.

    With these kinds of contracts in place, interesting possibilities
    arise. Here's one that tickles me: The elmcity service doesn't yet
    need to implement its own system of user registration. If my approach
    to decentralized event curation takes off, I might someday need to create a
    registration system and require curators to use it. But for now it's
    trivial for me to bookmark a delicious account and tag it as one that
    the service regards as authoritative for a hub.

    Likewise, the folks who provide the feeds trusted by curators and
    aggregated by hubs don't yet have to register with the service. For
    now, providers need only make feeds known to curators, one way or
    another. And curators who deem those feeds worthy of inclusion need
    only bookmark and tag them.

    These are the kinds of workflows that can arise when informal
    contracts are in place. They're cheap to create and easy to evolve.
    Here's a final example. If you're a curator who adds a new feed to a
    hub, you naturally want to see your new events merged into the hub as soon
    as possible. Normally you'd have to wait until the next aggregation
    cycle, which might be as long as eight hours. So I had to come up with a way for
    a curator to send an authenticated message to the service, telling it to
    short-circuit the wait and gather new events right away.

    My first thought was that here, finally, was the reason I'd need to build my
    own user registration system and require curators to use it. My second
    thought was,
    hang on, I already trust their delicious accounts, why not use those accounts as
    channels for authenticated messages? That's doable, but I didn't find
    a graceful way to do it. My third thought was: What about Twitter?
    Hence the Twitter contract:

    Among the settings that a curator conveys to the elmcity service, by way of a trusted delicious account, is the Twitter account to be used in connection with that curator's elmcity hub. The service will follow the curator at that Twitter account. By doing so, it enables the curator to send authentic messages to the service. The vocabulary used by those messages will initially be just a single verb: start. When the service receives the start message from a hub, it will reaggregate the hub's list of feeds.

    In a companion how-to article on O'Reilly Answers, I
    show how this piece of the service works. What's relevant here is that
    the code doesn't have to do very much. That's because the informal
    contract makes it possible to reuse Twitter in a novel way, as a
    channel for authenticated messages.

    In a world full of services like delicious, FriendFeed, and Twitter --
    services that can route feeds of data based on user-defined
    vocabularies -- you don't have to be a programmer to create useful
    mashups. You just have to understand, and find ways to apply, the
    Principle of Informal Contracts.


    Related:

    May 25 2010

    Haftung bei der Einbindung von Feeds

    Das Landgericht Berlin hat mit Urteil vom 27.04.2010 (Az.: 27 O 190/10) entschieden, dass derjenige, der RSS-Feeds in seine eigene Website einbindet – die im konkreten Fall von einer Tageszeitung stammten – dafür wie für eigene Inhalte haftet und auf Unterlassung einer Persönlichkeitsrechtsverletzung in Anspruch genommen werden kann. Das Landgericht benmüht hierfür das altbekannte Argument des Zueigenmachens fremder Inhalte.

    Es ist also stets riskant, fremden Content den man nicht im Einzelfall überprüft hat, automatisiert einzubeziehen.

    (via RA Dramburg)

    Reposted bykellerabteilschoenswetter
    Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
    Could not load more posts
    Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
    Just a second, loading more posts...
    You've reached the end.

    Don't be the product, buy the product!

    Schweinderl