Practical Open Source Business Models @ JDJ

As a person who is running a young company that develops Open Source software as a primary activity, I'm frequently asked to comment on the Business Models that are at play in the industry.
Whether you produce Open Source software or just use it, an amazing thing inevitably happens. Organizations on all sides of the producer-consumer spectrum put increasing amounts of energy and money into the one thing that matters most to any Business - the employees. This effect is key to understanding a successful Open Source Business model.
In this article I'll explain how that is, and what kinds of Business Models lend themselves well to Open Source software production and consumption. I'll do my best to frame my discussion in terms of classic Business concepts.
The Company Mission and Distribution of ProductThe goal of any company producing software is to get the right applications into the hands of the end user as fast as possible while making some money in the process. Open Source licensing is a nice vehicle to achieving those ends. As with proprietary software purchases, software is still transferred from producer to consumer and money still changes hands. But Open Source licensing allows that process to happen in a completely different way. With Open Source licensing the actual transfer of the software from producer to consumer is accelerated. This difference in product distribution means that the Open Source company invests differently than proprietary companies into Business infrastructure.
Here's why. An Open Source software company doesn't manufacture tangible things, really, but rather digital intellectual property. It's a pure services company. In the most basic scenarios, the company does not have to worry about protecting Source code or manuals once they are released to the public. Proprietary software manufacturers on the other hand need to make money selling the intellectual property itself, which means a significant investment into developing and protecting distribution channels.
Open Source licensing and the commercialization of the Internet simply eliminated the need to invest in distribution channels and Business partnerships designed to protect CDs in boxes and manuals delivered to a store.
Another significant difference has to do with the software license fee. The fee paid for a software license is nothing more than nonvalue-added concession paid to a software manufacturer for the right to use its intellectual property. From the supplier's perspective one thing becomes painfully clear when we put Open Source licensing side-by-side with proprietary software licensing: this fee is a barrier to the act of actually transferring software from supplier to consumer because consumers can't actually get the software until they come up with the money.
When you're selling software, this barrier is necessary. But when you're not making money off the software, it's a barrier that needs to be destroyed and one that confuses the consumer.
And differences in distribution channels of the software is just the beginning.
Open Source software is also forcing companies to be more in tune with the needs of customers. The mission of the Open Source software company is never that of selling software licenses. The mission of the company becomes focused on solving the customer's underlying Business problems that drive him or her to acquire software in the first place. The focus becomes turning the knowledge of experts into viable software solutions that address Business problems.
There are also incidental benefits to Open Source licensing. No wages are spent on software sales people, or creating global licensing schemes that work in a hundred countries. And, perhaps most appealing to the consumer, no money is spent suing the consumer over license violations.
Procurement Costs: Creating a Demand for Open SourceDistribution channels and company mission aside, the first thing about understanding an Open Source Business model is understanding how Open Source licensing allows companies to shift costs. Costs are barriers to success for any Business, and nonvalue-added costs are deadly sins. This is a big factor in driving demand for Open Source software because the costs a company incurs says a lot about the company's mission. Alaska Airlines buys airplanes, Weyerhaeuser buys trees, and McDonald's buys beef. Get the point? Unless a company is in the Business of selling software it has no reason to purchase it.
Software procurement and IT support, as we say, is a secondary function of Business. Software is a necessity in many industries, but financially speaking it's just so much overhead. So capital expenses associated with purchasing and acquiring software should naturally be as small as possible.
In so much as Open Source licensing removes the costs associated with software procurement, it also eliminates the nonvalue added cost of the software license, which is nothing more than a permission slip to prevent you from getting sued. There are no purchasing forms to fill out or requisitions to sign off on; there are no software audits or legal issues to worry about.
You may be surprised, for example, to learn that some hospitals spend as much on software licenses as they do on surgical supplies. Group Health this year is in the middle of spending $30 million on the installation of a proprietary clinical medical records system. Kaiser Permanente is reportedly spending about $1.8 billion to implement new software. It's impossible for us to know how much of those budgets are earmarked for software licenses. But you can be assured that if the software licenses could be avoided they would be. That amount of money pays for a lot of pain killers.
The lesson here is that the need to control procurement costs of IT is a key factor in the demand for Open Source software. Open Source licensing gives companies the ability to control costs associated with software procurement in a big way. Once management approves the use of the software, the mechanism for delivering the product to the desktop is right there on the network. Software is downloaded and installed at a pace that fits the company's time line.
The Supply End of Open SourceA great concept like Open Source licensing is useless until there exists a Source for the software. That is, someone has to write the software and distribute it. It could be said that in the beginning the world's supply of Open Source software came from college students and working professionals disgruntled with what was available. While the commercialization of the Internet has always been the critical distribution channel for getting the software to the end user, we still have to account for the ultimate Source of software in our Business model - the developers.
Some argue that the collaborative efforts of Open Source development such as that found at gnu.org are a perfect example of a viable Open Source Business model. Those organizations have existed primarily as nonprofits that receive donations.
You can live on donations if you want, but that just begs the question: What does a for-profit company look like when the only IT product it produces is Open Source software?
Answering this question is a useful exercise that will lend insight into how to build up an Open Source company. No fair answering this question by dehumanizing capitalism or saying for-profit companies damage society. No fair trying to make up for lost profits by packaging Open Source products into boxes for retail stores. In our game of defining a "pure" Open Source company, the trick is to define a Business model that puts the development of Open Source software at the core of its mission with nothing more than a developer, a computer, and an Internet connection. It's not easy.
The answer may very well be a pure services approach where the software is a by-product of industry-specific consulting services. In this approach, the only thing the consultant sells is time. Software becomes a logical result of the work being done. The differentiation and success of the consultant in the marketplace is based on efficiency and quality of work. If the client is unhappy with the quality of work or efficiency of the consultant, the client finds someone else.
For existing examples you might look at the legal profession. When we hire a lawyer we aren't paying for letters, documents, or court briefings. We don't pay, say $1,000, for a court document. We pay the lawyer for her time to prepare the material and present it to the court. The fact the document exists is merely a by-product of the work that was done. What differentiates your lawyer from another is her ability to ultimately get results and effectively represent her clients.
To see how this software-as-a-byproduct-of-services approach might work for Open Source development, we have to be willing to redefine the traditional role of the software developer. The software developer must cease to be someone who writes software in a vacuum for a skilled professional, such as a doctor, to use. The software developer and the skilled professional must become one and the same. Or, at the very least, the skilled professional who actually does the consulting must be able to sell software development services as part of his normal consulting. He must become an effective IT project manager at the very least.
To explain why this is the case, let me suggest three basic principles that, when followed, can allow a skilled professional in any profession to make a living, at least in part, writing Open Source software.
The first principle is that software embodies the unique knowledge of a specialist and the need to apply that knowledge to managed data is what drives software development in the first place.
The second is that software is nothing more than a deliverable.
The third principle is that the software should stimulate standards of service in an industry if the Open Source company is to be successful.
Let's take architectural services as an example. When an architect designs a building, a number of things are produced. The plans for the building, environmental impact statements, materials lists, and a lot of other data are generated. That information must be assimilated by others to actually get the building constructed.
For the sake of argument let's assume the architect is also a computer scientist or at least knows how to manage a staff of programmers. If the architect is able to deliver custom software tools, such as a building materials management system, the architect has met the first principle: the architect's unique knowledge implemented in software can help others manage the data more efficiently.
By including the actual software as part of the other deliverables, such as the building's plans, he has met the second principle: the software is a byproduct of the work being done. Remember, the architect is designing a building as his primary activity.
Finally by making the software available under an Open Source license, he helps stimulate new standards of service within architectural services. Specifically, that architects provide software solutions with their building plans. You might correctly expect that wherever new standards are adopted, new services follow. That means more revenue for architects - especially the architect who sets the standard.
The end result, hopefully, is that the architect helps everyone around him work more effectively by stepping into the role of a software developer - or at least that of a software project manager. Of course you would hope that in doing so the architect differentiates himself from other architects - an important thing to do in a free market economy.
It's About the ProfessionalLet's look at how putting the expert at the center of an Open Source company effects the Business model. Simply stated, the company must be designed to bring together professionals responsible for Open Source development and make sure they get paid. It must also absorb risk and prevent them from getting sued or their intellectual property rights stomped on. It must somehow make it feasible for the person to work in a given profession and author software as a dual mission.
There are number of ways to accomplish this, but in general building up support structures for key individuals is an important thing to do. Southwest Airlines is famous for doing this on a broader level. The company is known for turning corporate structure on its head. At that company the role of management is to support the front-line employees, as opposed to whipping the employees around until they somehow make enough money for the company. The employee is given the reSources she needs, and then entrusted to do a job. The role of management is to support the employees doing the work. You might expect to see something similar in a successful Open Source company.
Consequently, Business Models that support Open Source development as a primary activity will tend to put the unique skills of individuals in the limelight. That company will make sure the consultant has access to the reSources he needs and is a happy worker.
This may be unique in software development circles where workers have traditionally signed away their intellectual properties and have lived in cubicles in exchange for pay. But treating workers like superheros is a long-standing tradition in the consulting trade of any profession.
When a customer hires a consultant, he hires that person and not just some well crafted set of skills. Likewise, when the end user utilizes a software application, she's actually trusted her Business to the very person who wrote the software.
So, as the Open Source consulting firm, if you're successful in combining the key people in a given profession with an Open Source solution, you're likely to have a winner of a Business model.
For those of you not comfortable with that notion, consider this: if you're not comfortable trusting your Business to the person who wrote your software, you might be using the wrong software. That software is a direct extension of the person's knowledge about your Business and industry. Open Source software companies will have an awareness of that in principle.
Open Source All the WayThe whole approach of professionals in their careers of choice becoming Open Source purveyors makes even more sense when we consider that the professional can provide Open Source solutions that absolutely do not require any software licenses to be purchased. The code base for Open Source applications is so large now that no operating systems, development tools, databases, or Web servers ever need to be purchased.
All of the money that would normally be spent on those software packages can be redirected to people who directly support the professional. That includes the software developers who created all that software, such as databases and operating systems, in the first place. If you're a company developing a product that uses PostgreSQL, a popular Open Source SQL database server, chances are you'll get one of the original developers to make a change on your behalf if you fund the work. Even if you can't get your private wish list of changes implemented, at the very least you'll be empowering the people who can make a change in the software product, if it makes sense to do so.
Furthermore, because the software a professional develops can be used throughout that person's industry, it can be used to address needs in an industry vertically. Suppliers above the professional and customers below the professional in the industry food chain can take advantage of one person's creative software designs.
Barriers to EntryIdentifying barriers to entry are also critical to understanding what Business Models will work. When taking the pure services approach that I have suggested so far, the barriers to entry for Open Source software development parallel that of other service-based professions such as legal services
The principle barrier to entry, above all others, is skills acquisition: the ability to recruit people with sufficient skills and experience to do the actual work. As I suggest earlier, the people need to be something of a super consultant. They have to be skilled in a particular profession like manufacturing or medical services but also have an understanding of computer science and software development.
Here's why: a consulting firm relies heavily on the individuals doing the work and their reputation. If you are planning on being the consultant yourself or are unable to hire others as regular employees, you will need to invest heavily in your training and "do your time" in a particular industry.
The second barrier to entry worth mentioning is the cost of obtaining the computing reSources you will need to operate. Internet connections and computer hardware are not free. The nice thing about Open Source software, however, is that this barrier is relatively low because much of the software you'll need runs just fine on older computers.
The third barrier to entry you can expect to run up against is time. If you're going to be an Open Source consulting firm, it would behoove you to utilize Open Source software in your Business exclusively. This means taking the time to learn a lot of software intimately. Relying on proprietary software products can confuse your customers because it reinforces the belief that Businesses cannot run without proprietary software products. It can also hamper your reputation, unless you are actually developing an Open Source application to run on a proprietary operating system.
Time also becomes a barrier when no application exists that meets your needs. In this case, you will need to take the time to actually create a new application to address those needs. The time you spend doing that may delay the development of your company temporarily, especially if it's an application such as a payroll accounting system.
Ironically, capital is typically not a significant barrier to entry in today's Open Source market place. A computer scientist with a five-year-old computer can develop Open Source software that can revolutionize entire industries. Linus Torvalds, for example, developed Linux with nothing more than an average computer. There was no special equipment or supplies to purchase, and it wasn't even necessary for him to hire people. All it took was his knowledge of computer science, creativity, and some extra time on his hands.