OPINION
Free Software Shouldn't Mean You Can't Make a Buck

Richard Stallman, the founder of the GNU Project, speaks at great lengths about preserving the ideological purity of free software, and in his vision of the future, computer software development is modeled after mathematics and science research, where all research and development is open. So far as Stallman is concerned, proprietary software production is unethical and should be avoided. As he detailed extensively in The GNU Manifesto, traditional closed source capitalism should be rejected in software development and replaced with a post-scarcity economy.

While I admire that sort of optimism and long-term vision, I take a more market-driven approach to the software and technology industries. In my last article, I wrote in general terms about using Free and Open Source Software as a platform on which to base a profitable business. I want to follow up on that article with some specific ideas and examples for how to use these tools to create a successful enterprise.

GPL vs. BSD

First of all, I don't want to get too mired in talking about licensing schemes, patents, copyrights, and/or trademarks, because I think a lot of that talk is counterproductive or at least irrelevant to Linux ubiquity. That said, I should clarify my position on BSD vs. GNU General Public License licenses (subject to change as I grow older and more or less jaded). Personally, I see great value in BSD-style licensing.

Unlike the copyleft GPL, which prescribes a freedom and responsibility to share, the BSD license is basically freedom to get robbed. Under the terms of the BSD license, it is perfectly legitimate to release closed source proprietary software without providing copies of the source code. Many high dollar companies on Wall Street have used BSD-based software as substantial parts of their businesses; BIND, for instance, the popular DNS server is a widely-deployed program that makes the Internet work.

If you write proprietary programs that you license as BSD or base on existing BSD-licensed software, you can sell them without providing a copy of the source code. Obviously from a business standpoint, this is a good selling point. You will need to be careful to follow the terms of the GPL license, as well, and link to LGPL (rather than GPL) software, but being able to release proprietary software on Linux is an area where some companies like to operate. With the BSD license, you're welcome but not compelled to release your source code.

Business Reality

At some point, proprietary software outlives its usefulness as proprietary software and should naturally become open source; usually because someone else wrote a free (GPL) version of your proprietary program and you're unable to charge for it. When this time comes, you can release your source code, licensed under the same BSD license, and give other creative entrepreneurs and engineers an opportunity to use your software in their own ventures. In this way, BSD functions as a sort of GPL for business, but it would not function that way if it weren't for the GPL itself.

Whereas proprietary software is all well and good for businesses looking to profit off of end users, it's not especially hospitable to end users who just want cool free software functionality. The GPL license ensures that all associated works are also GPL; it creates a free software ecosystem that defends itself by ensuring that if you use free software licensed under the GPL in your own software, yours must also be licensed under the GPL. Moreover, it works as a counterbalance to the BSD license; when someone develops a clever proprietary application, the GPL provides a venue for developers who like the idea behind the proprietary software to work together in order to make a free version.

While the proprietary app developer is motivated by money, the free software developers are motivated by mimicking functionality. In order to remain relevant in the marketplace, the proprietary developer has to develop new features in order to not lose its users to the free software version of the original proprietary program; if a proprietary software developer wants to stay in the game, this is the least it can do.

Compensating Developers

Licensing aside, there are a number of avenues for Linux-related businesses that don't even involve running afoul of RMS's rigid moral hegemony. Whereas in The GNU Manifesto, Stallman discussed possibly paying developers through a software tax at a national level that would route funds to the National Science Foundation which could distribute them for development, I would like to throw out a few similar -- albeit more modest -- ideas to help fund free software developers. The Linux Fund is a non-profit organization that accepts tax deductible contributions that it uses to fund open source software projects.

While software development is no doubt important to the livelihood of Linux, supporting users is arguably as important. As such, I can see value in companies that help out Linux-related businesses with public relations and marketing . Whether run as regional cooperatives or non-profits where members paying dues or as straight for-profit ventures where clients pay fees, consolidating resources in order to help increase awareness of Linux-based businesses and users within the marketplace will help develop the network that connects the business ecosystem.

Obviously the software support business model is as old as (if not older than) The GNU Manifesto, but now that we're a couple decades into the Information Age, we have a better idea of things that do and don't work in the Linux business. With countless distros that can be customized in any number of ways, this is especially clear in the support sphere. If we can have auxiliary businesses that provide business development services and contacts for Linux-related entrepreneurs and organizations, those entrepreneurs and organizations can surely become more specialized. As support businesses diversify, each of them can contribute more proactively to the community software projects they use to do their jobs, helping those community-based projects to move forward as well.

Support for Dummies

Finally, we have the support resources business model, which is perhaps the most traditional of them all. O'Reilly and Wiley Publishing (for Dummies) have done gangbusters in this area, but they have no more a claim to the future of educational resources than any of the rest of us. Whereas many technical people use free information found on the Internet in order to learn and troubleshoot, this enterprising demographic makes up only a small section of the overall population. Correspondingly, there are broad markets waiting for a specific presentation method that speaks to them. Schools are probably the most obvious ideal customer , but they're by no means the only one.

At one end of the spectrum, we have individuals and businesses deploying Linux-based operating systems in all kinds of settings that need materials to help them figure out how to do the specific tasks they want to do without having to learn all the fundamentals that make those specific tasks possible, and at the other end, we have people who want to learn it all but are only 6 years old. Both of these groups, and many in between them, are under-served and ripe markets.

Obviously this is not a comprehensive list, and I welcome input any of you have on the future of Linux in business. I wanted to provide some ideas to help counter the proclamations I sometimes hear that the only available business models for Linux-based business are Software as a Service, advertising and support. I value having a platform like Linux that provides numerous implementation schemes, and I want to help it mature so that it can more handily rival the various commercial operating systems available today.