Recently, as I was browsing the shelves of my local used book store, I realized that I was engaged in "piracy" of exactly the same kind as what the legacy entertainment industry has slammed as a scourge so terrible that it is worthy of giving up our online freedoms to protect. This is what SOPA is supposed to protect us from.

Can artists actually make money on a free software driven free culture project? Having established the motivations and the basic principles in the first two parts, I'm going to look at the big picture here: how money would be distributed among major parts of the project (drawing partly on knowledge accumulated from the proprietary film and television industry -- taking into account the differences), where the money would come from, and what sort of income might be realistic based on the few projects that have gone before us.

Most of the assumptions on which our present economic system is based are based on nothing much better than "conventional wisdom": which is a fancy way of saying "it just sounds plausible". Sometimes conventional wisdom is wrong, and that's what the first part of this book has been about: six things that ought to be impossible if conventional wisdom were correct. But if the foundational assumptions of our economy are false, then where does that leave the economy? And if it's no longer standing on a firm foundation, then what are the new rules?

The bazaar development model turns out to be amazingly versatile: it seems that most software, even things you wouldn't think would be feasible, can be developed using such an approach. But there has to be some working core software before the community will have enough interest to contribute to a project, and there are some projects where that is really too much work for one person to do.

One such area is sophisticated 3D graphics applications, like Blender (and also Computer Aided Design applications, like BRL-CAD). Such projects typically need some sort of seed project in a "cathedral" mode in order to get started. Other projects, such as creative endeavors, are simply not going to be as successful in the committee atmosphere of a community-driven project.

In such cases, there's a need to simply accumulate capital and pay people for their work. But surely this is impractical for a loosely-bound group like the free culture community? Let's look for some counter-examples.

A new conventional wisdom began to spring up around free software, led in part by theorists like Eric Raymond, who were interested in the economics of free software production. Much of this thought centered around service-based and other ancillary sales for supporting free software. Based on this kind of thinking, it's fairly easy to imagine extending free licensing ideas to utilitarian works. But what about aesthetic works? The Creative Commons was established in 2002, largely to solve the kinds of licensing problems that aesthetic works might encounter, and it has been remarkably successful, pushing the envelope of even this newer wave of thought. Today, Creative Commons licensed works number in at least the tens of millions. And more than a quarter of those are using the free "Attribution" or "Attribution-ShareAlike" licenses.

With any paradigm shift, it is difficult to see the new world from the old one, even though it is glaringly obvious once you've crossed over. Empirical evidence is one way to bridge the gap. To that end, I want to show some solid evidence for the "impossible" things that commons-based peer production (CBPP) has already accomplished—things that the old conventional wisdom would tell us "can't be done". This week, I'll look at what is probably the most obvious case: free software.

There are really two bazaars that fire the boilers for free software: one dominated by talented amateurs who create for love; the other, by professionals who create for money. This creates a curious bi-modal nature to the free software/open source community: there's always a certain amount of tension between the schedule-driven bottom-line interest of commercial entities like Novell, Red Hat, or even Canonical and individual hobbyist developers.