Pretty much everybody who's talking seriously these days about asking users to pay for news content is pointing at the same model: Leave the website open to casual visitors, but require heavy users to sign up as paying customers. Let people see perhaps half a dozen stories a month, but if they show signs of high interest, present them with a bill for the content they're consuming.

That's the model being planned at the New York Times. It's the model that Journalism Online has described as having the most support in its talks with newspaper publishers. (I don't know what model Rupert Murdoch is planning, but then I suspect he doesn't either.)

The goal of this model is to preserve most of the site traffic that enables an advertising revenue model to work, while getting serious users to support the journalism they find valuable.

But there's a technical problem: HTTP cookies. To let casual visitors in the door while challenging regular users to pay, you have to rely on cookies, and the cookie monster won't let you do that. Cookies just aren't very reliable for that purpose.

Lots of websites require that cookies work. You can't log in to buy a book, schedule a hotel room, post a comment or check your bank balance without cookies. They generally work fine for that purpose. So where's the problem?

Those sites use what are called session cookies. When you log in, the website hands your browser a token that uniquely identifies you. If you log out, or close your browser, or reboot your computer, that token is thrown away.

This is fine for a short session, but to track how many pages you've read this month on the Daily Bugle's website, we're going to need cookies that last at least a month.

Fortunately, the cookie standard supports long-lasting cookies.

Unfortunately, human beings throw them out.

All modern browsers can be configured to accept cookies but destroy all cookies at the end of a session, or on a schedule (perhaps monthly). This takes some action on the user's part, so most people don't do it. But many do.

In fact, a Comcore study found that 38% of users cleared out their browser cookies during the month of December 2006. And 7% of uses were "serial resetters," clearing their cookie stores four or more times a month.

This has a lot of disturbing effects on your traffic measurements, but let's stay focused on the paid-content issue.

Every one of those cookie-clearing visitors is going to knock a hole in your "soft" paywall, because your paywall can't know who they are after they've flushed the cookie jar. They're going to waltz right through that hole and read whatever they want. They will never see your "please pay for access to this website" request.

And it's going to get worse. Newer browsers have "anonymous browsing" modes that make this easier, and if you expect your users not to take advantage of such tools, you're fooling yourself.

I suspect that all of this will be greeted by "well, duh" by web geeks everywhere, but unfortunately most journalists and managers have no idea how these things work, so it needs to be said. You can't have your cake (a working ad model) and eat it too (a genuinely secure paid-access model).

You have to settle for a numbers game. Can you achieve a workable, "good enough" mix of free, paid, and "should have paid but didn't" access?

As you put together a spreadsheet to analyze this, be very careful with your assumptions.

So the New York Times has announced it will begin charging for access to its website, using a metered model similar to the one I discussed recently. The reactions have been predictable. I want to focus on one small angle: What we won't learn.

We won't learn a thing this year, because they're not doing it until 2011.

This may place the Times in a position of being out of sync with the marketplace. The greatest force driving the whole "charge for content" discussion has been the recession's rollback in general advertising expenditures. By 2011 we should see a significant resurgence in ad revenues. That will increase the economic risk in the Times' experiment.

We won't learn how this applies to regional daily newspapers, because the New York Times isn't one.

Think about it: If the Times had anything to teach regional dailies on this subject, it would work both ways. Regional experiments could inform the Times' decisionmaking.

The New York Times owns 16 other daily newspapers that could be used as test cases. Would you bet the big farm first? Of course not. If you believed the learnings would be portable, you'd try it in a less risky market.

But the people at the New York Times know the Times is fundamentally in a different business than regional dailies. We should know that, too.

We won't learn anything about what the market will bear. A single experiment with a single price point by a single newspaper is just a stab in the dark.

We might, however, discover how many New York Times readers will migrate to the Guardian, where editor Alan Rusbridger has said "it would be crazy if we were to all jump behind a pay wall and imagine that would solve things."

This is a message to prospective Drupal developers. I'm going to propose this as the First Rule of Coding for Drupal: We do not write code for Drupal.

I've been thinking about this for awhile, but what pushed me over the edge was Tom Davidson justifiably poking on the crew of exiles from a certain industry magazine, and his pointing to this Growthspur post that insists starting a local site "is easy and cheap (and don't let anyone tell you otherwise)."

Davidson and the Growthspur folks are 95% right. Start with easy and cheap. Get it done, and then (only then) face the hard and expensive. I'll discuss the other 5% down at the bottom of this post.

I've been using Drupal since 2005, beginning with a prototype for an experimental community site. Now it's at the core of the core of what we do at work: supporting our newspapers' efforts on the Web.

Over the years I've seen a parade of developers come through our organization, struggle with Drupal, learn about Drupal, and in many cases move on to work for consultancies on really huge projects like the White House website.

The consistent mistake that developers make is to plunge in with the intent of writing code.

We do not write code. That's a rule you should make with the expectation of breaking it, but with the intent of keeping it as much as you can.

If you're a developer with any fluency in PHP/MySQL/HTML/CSS, this is a hard rule to face. If you're new to Drupal and don't understand the vast landscape of contributed modules and themes (design packages), it's especially hard. You know your tools. You know how to get things done. So you reach for the comfortable and the familiar. Who minds if you're reinventing the wheel? It seems faster to just do it your way.

The hidden costs are huge. While you're reinventing the wheel, you're not moving on to the next problem. You're creating a stack of code that has to be maintained. You're writing bugs (everybody writes bugs) that have to be squashed. Even in something as "simple" as a site design, you could be creating hundreds, maybe thousands of lines of code that have to be painstakingly examined, upgraded and re-tested a year from now when the site moves to a new version of the core application. Are you documenting everything you do? What's the next guy going to think of your work?

There's another cost, though, and it's actually bigger. When you write bespoke tools, they tend to be built to do exactly what you're trying to accomplish.

That's not a good thing.

The Drupal module landscape has some amazing tools that are quite the opposite. CCK, Views, Imagecache, Nodequeue, Panels and several other contributed modules have become essential to tens of thousands of Drupal projects because they assume you're not really clear about what you're trying to do and you're likely to change your mind. Or your boss isn't clear, which is even more likely.

Real-world testing, iteration and course changes are far more likely to lead a business to success than ironclad central planning. If you're a developer, it might seem like "the boss doesn't know what he's doing." OK, that's one way to look at it. The truth is that none of us knows; we have some guesses, and we're trying to find out what we're doing. Working quickly, configuring off-the-shelf tools, is an important way to get there.

So you learn to use the application, rather than writing code. You recycle other people's work. You negotiate with your bosses and make compromises along the way in the interest of getting real-world results, and real-world learnings, quickly. And two things happen that are central to your work as a developer:

1. You discover where the really hard 5% really is, rather than mistakenly thinking the majority of the project is coding. You will find something that really needs to be coded from scratch, and you'll be able to focus on it.
2. From working with the generalized tools, you learn defensive design patterns -- ways to anticipate changes, to implement your bespoke code so it can be reconfigured on the fly without additional coding, and accommodate unexpected course changes.

Everything I'm saying here will come as no surprise to longtime Drupalistas. If you Google "Drupal hall of shame," the top result is a "Similar Module Review" discussion group focused on reviewing potential cases of reinventing the wheel. If you'd like to become a Hall of Famer, start out by staying out of the Hall of Shame. When you eventually apply for a CVS account to release your modules on Drupal.org and become a rising star in the Drupal firmament, you're going to face a brutal review of your application. Be prepared to explain why your work is unique.

I've been working recently on a Drupal project for a European media company -- currently on hold -- that refreshed my point or view on all of this. I can code, and in fact have a couple of modules I've released on drupal.org, but I'm not a programmer and expect to outsource some parts of the project. As I worked, I was struck by how quickly Drupal has evolved as a "no coding" platform. Things that seemed just out of reach a year ago are now point/click/configure. It's been said (by Dries? I can't find the reference) that Drupal isn't finished until it can wash your socks. Sock-washing is still in that hard 5% layer, but a lot of what you need to do is already done for you.

In the newsroom of the first daily newspaper that employed me, Editor & Publisher magazine was forbidden because of the employment classifieds that justified the "editor" part of its title. The editor regarded it as subversive literature, luring his staff to faraway places with the promise of riches, or at least a living wage.

I don't remember what a subscription cost, but it was out of reach. Half the newsroom banded together to pool funds and buy a single subscription -- a hefty investment for those of us who were paid $2, maybe $2.50 an hour, to cover the news of the day in Champaign, Illinois.

We passed around our weekly copy in a brown paper bag like a bottle at the bus station.

After four or five months, the reporter in whose name the magazine was delivered got a job in a bigger city, like maybe Peoria, and the E&P subscription disappeared with him. The rest of us were left behind with the collection of broken chairs and malfunctioning typewriters.

Today the Nielsen Business Media people pulled the plug on Editor & Publisher, announcing that the magazine will be shut down as it sells off other media trade publications that it operates: Adweek, Brandweek, Mediaweek, Billboard and the like.

Editor &Publisher shared too many characteristics with the newspapers whose industry it covered. Historically weak on content and poorly designed, it was reliant on the cash cow of classified advertising. For those of us struggling, underpaid, at the beginnings of our careers, it was a welcome glimpse into a bigger and more promising world. And, also like many newspapers, it eventually passed from the control of a family to being just another brand in a corporate stable.

We could blame the Internet for destroying E&P by making it superfluous.

Or we could blame the Nielsen Company, which trashed its classifieds franchise through mismanagement, entangling the listings with perhaps the worst online classifieds presentation on the Internet and mingling journalism jobs with listings for installers to put Nielsen audience-measurement boxes in the homes of TV-watching families. They drove away the audience and employment listings to startups like JournalismJobs.com and the Poynter Institute's database.

What was left dwindled to a monthly, I think. Despite the good work of people like Mark Fitzgerald and Jennifer Saba, I just quit reading it. The magazine no longer represented a welcome glimpse into a bigger and more promising world. We all are wired now. Distance and scarcity are abolished.

For that, I suppose, you can blame the Internet. I will choose to remember E&P as the magazine of my youth, the one my dad brought home from his newspaper job, the one with ads for exotic jobs in the great hunting and fishing paradise of the Permian oil basin in Texas. On the front: A cowboy advertising the San Francisco Chronicle, because the Chronicle means the West. And in the back: An essay by Robert U. Brown. Shop talk at -30-.