Some of us work for money. Some of us work for love. Some of us work for both, or just because we feel compelled or obliged.

As a journalist, I work for all those reasons, except money—meaning I write as much as I ever did, but I rarely get paid for it. So I make up the difference with other kinds of work for which writing and talking are still marketable skills. The same goes for nearly every journalist I knew back in the heyday of the trade, before everything got sucked into the Net.

Now, thanks to the Net, there is more news than ever, from more sources than ever, coming through more channels than ever. Could be there's more money than ever paying for it too. I don't know. I also don't know what percentage of the total flow is news or journalism. Now it's all just "content".

No journalist of any quality (other than bad) thinks what he or she produces is "content". Nor does any musician, or artist of any kind. We hate the term "content". It sounds like packing material, or container cargo. But hey, that's the world we live in now.

It's a good thing the Net we have today is only about 20 years old (1995 was when the NSFNET was decommissioned, opening the whole Net to commercial activity), and all businesses and business models are provisional anyway. They may do for now, but none of them foreclose future possibilities—just as no breed of commercial UNIX (launched by AT&T in 1973) foreclosed the possibility of free and open alternatives, such as Linux. (Historical note: Linux Journal was launched alongside Linux 1.0 in 1994. And we know what's happened to UNIX and Linux since then.)

So let's look at business models for free (as in beer) artistic goods as a blank slate.

I know: we can't ignore copyright laws, rights-clearing norms and industries (publishing, Hollywood) that call folks like us "pirates" and hold captive regulators by the short hairs. None of that will matter if we make all of them happy by finding a way to get them—and the artists they represent—more money than they've been getting by coercive means. If the answer is money, the only question is how.

Let's start with this thesis: Information wants to be free, but value wants to be paid for.

If that's true, the trick is to make it as easy as possible for anybody to pay for anything they like, wherever they find it, even if that thing is as small as a like, a tweet, a post, a graffito or a tune heard just one time—and even if all anybody wants to pay for that thing is a penny.

We do have proof that lots of people will pay for things they can get for free. Apple, for example, proved that people were willing to pay 99 cents for a song they could also get for $0 on Napster or Limewire. I've also conducted tests of value by asking audiences at my talks in the US if any of them listen to public radio. Usually most hands go up. Then I ask how many of those listeners pay for the privilege. About 10% of the hands stay up. Then I ask how many would pay if it was real easy. The number of hands doubles.

Here's what I suggest for an approach:

1. It needs be free-as-in-freedom as well as free-as-in-beer.

2. It should make it easy for anybody to pay any amount for anything they like. Even if it's not a thing (a song, for example).

3. It should be programmable. So, for example, one could set things up so it's as easy to throw a penny (or more) toward anything, anywhere, as it is to like something on Facebook.

4. It should be a capability that can be added to lots of different things, rather than a standalone thing, such as an app.

5. It should make use of APIs. That way, for example, one might be able to throw a penny (or more) at every tune one tags with the Shazam app.

Those are just off the top of my head. Add more of your own. It's easy if you think outside the boxes of business-as-usual and context-as-usual (such as Facebook, Twitter, Apple and other silo'd sites and services—or thinking "there needs to be an app for that").

It also helps to think inside the boxes that have produced millions of free and open-source code bases, and useful standards and protocols. Those are the boxes where the base imperative is making stuff as useful as possible for every purpose to which that stuff can possibly be put.

As it happens, I proposed one of these a few years back. It's called EmanciPay, currently described this way on the ProjectVRM wiki:

EmanciPay is a payment framework for customers operating with full agency in the open marketplace. It operates on open protocols and standards, so it can be used by any buyer, seller or intermediary. Simply put, EmanciPay makes it easy for anybody to pay (or offer to pay) —

• as much as they like

• however they like

• for whatever they like

• on their own terms

— or at least to start with that full set of options, and to work out differences with sellers easily and with minimal friction.

EmanciPay turns consumers (aka users) into customers by giving them a pricing gun (something which in the past only sellers used) and their own means to make offers, to pay outright, and to escrow the intention to pay when price and other requirements are met. Payments themselves can also be escrowed.

While EmanciPay was first conceived by ProjectVRM as a way to make live payments to nonprofits and online publishers, it is also positioned as a counterpart to sellers' subscription systems in what Zuora calls the "subscription economy" (https://www.zuora.com/what-is-zuora), which it says "is built on ever changing relationships with your customers". Since relationships are two-way by nature, EmanciPay is one way that customers can manage their end, while sell-side systems such as Zuora's manage the other.

In "EmanciPay: A Content Monetization Plan for Newspapers", I say:

Think of EmanciPay as a way to unburden sellers of the need to keep trying to control markets that are beyond their control anyway. Think of it as a way that "free market" can mean more than "your choice of captor". Think of it as a way that "customer relationships" can be worthy of the label because both sides are carrying their ends of the relationship burden—rather than the sellers' side carrying the whole thing (as CRM systems do today).

I think EmanciPay can work as what Bruce Sterling calls a design fiction:

A formal definition exists: "Design fiction is the deliberate use of diegetic prototypes to suspend disbelief about change."

There's heavy freight in that sentence, but most can be disposed of promptly. "Deliberate use" means that design fiction is something that people do with a purpose.

"Diegetic" is from film and theatre studies. A movie has a story, but it also has all the commentary, scene-setting, props, sets and gizmos to support that story. Design fiction doesn't tell stories—instead, it designs prototypes that imply a changed world.

It's nearly impossible for any threatened businesses to imagine what will disrupt them—especially when they are busy fighting disruptions full-time already. This is why publishing, entertainment and other content-pumping businesses can't grok the likes of EmanciPay—at least not until they see a prototype such as might be produced in a design fiction exercise.

But geeks who have already changed the world are in a much better position to imagine out the possibilities, and actually assemble the code required for it. That's why I'm talking about it here.

EmanciPay: http://cyber.law.harvard.edu/projectvrm/EmanciPay

Project VRM Wiki: http://cyber.law.harvard.edu/projectvrm/Main_Page

Zuora: https://www.zuora.com

Subscription Economy: https://www.zuora.com/what-is-zuora

"EmanciPay: A Content Monetization Plan for Newspapers": http://blogs.law.harvard.edu/vrm/2009/05/28/emancipay-a-content-monetization-plan-for-newspapers

CRM: http://en.wikipedia.org/w/index.php?title=Customer_relationship_management

Bruce Sterling: http://en.wikipedia.org/wiki/Bruce_Sterling

"Patently untrue: fleshy defibrillators and synchronized baseball are changing the future": http://www.wired.co.uk/magazine/archive/2013/10/play/patently-untrue

NFSNET: http://en.wikipedia.org/wiki/National_Science_Foundation_Network#Commercial_traffic

History of the Internet: http://en.wikipedia.org/wiki/History_of_the_Internet