American history is rife with success stories. History books, classrooms and the media are full of stories of people and businesses who have achieved great wealth and renown through their own sweat and tears. However, with the advancement of Internet technology, businesses of a nontraditional nature have emerged, and the "business" of shared knowledge has taken on new meaning. Open-source software projects are becoming full-time businesses of their own. Despite the emphasis on freely shared source code, project leaders and their communities are finding themselves increasingly reliant on traditional business models to sustain their projects and users. A new generation of enterprising people is faced with the challenge of applying successful business practices in new and innovative ways to turn their open-source projects into success stories of their own.

At the beginning of any project is the idea, and whoever thinks of that idea is usually strapped with seeing it through to fruition. The leader of any open-source project will say that the beginning is lonely. With luck, there might be a partnership established early on to help share the workload, but more than likely the majority will fall on the person responsible for initiating the project. Very few have the resources to quit their day jobs, so an immense amount of work needs to be done on personal time. Relaxation, personal interests and even personal relationships may fall by the wayside for a time until the project is well established. This alone is often enough to halt a promising project before it has really begun. Few are willing to put in the hours, and few possess the diligence to see the project through. In time, however, successful project leaders are able to find a balance. A community takes shape, contributors come on board, and the project leader begins to reap the rewards of endless hours spent writing code by candlelight while the rest of the world slept snug in their beds.

Once a project really takes shape and contributors begin aiding its growth, the project leader often finds a new dilemma to face: finances. Eventually, everything comes down to money. If the project is really going to flourish, it's going to need full-time attention. This is the point of no return for the open-source project: Will the project continue as is, or does a business need to be built around it? Is the project going to be forced to become a product? Some turn toward a dual-licensing approach, meaning that the product is free for personal use, but a licensing fee must be paid for commercial use. For many, a compromise has been made by building a business related to an open-source project. The open-source project remains free, while the business associated with it helps fund its growth. In either instance, a business approach is implemented. At first, the only full-time employee on staff may be the project leader; however, as the project grows, the leader will be faced with running a full-fledged business. That means making an early distinction between want and need. It's far too easy to take the profit and run, but it's vital that caution be exercised. The project leader must consider himself an employee, and pay himself accordingly. No company would ever pay its employees all its earnings. Progress is often unsteady, and one profitable year may be negated by the next year. If the project leader chooses to make the open source-related business his full-time career, he must carefully determine how much he needs to pay himself, and pay himself only that.