Now the issue is finding that "someone else". In the Funambol case, the community is virtually everybody in the world, including individuals, universities AND enterprises. "Someone else" is mobile telecommunication carriers. The carriers have needs that are distinct from all other users. They target millions of users. They target consumers. It is the same core software but with different features that the open source community does not care much about. Segmentation based on user base makes it easier to plan features that eliminate the natural tension between open source and commercial versions.

Another open source business model consideration involves technical support. As time goes by and a category of software matures, there may be less of an opportunity to monetize it by selling licenses for additional functionality. Conventional wisdom in this case may be that a company can succeed by providing support and related services. But if you really have the best interests of the community in mind, your natural tendency should be to provide transparency and as much information about the project as possible, including documentation, troubleshooting tips, best practices, bug reports and more. The more resources the community has at their disposal, the more valuable the project becomes, leading to a self-reinforcing viral adoption of the software.

This reminds me of a story about a colleague who worked at one of the largest software companies in the world. He was responsible for planning the next version of their second largest product that generated hundreds of millions of dollars in software licenses and professional services per year. When he first started this project, he surveyed the product's users to find out what they wanted. At the top of their list was more information about how to use the product to accomplish complex tasks.

Upon reviewing this with the management team, they decided not to provide that information because they believed that it was this "hidden" knowledge that allowed them to generate major revenue. If the users could just read about how to implement the software by themselves, it would significantly reduce the money that the company could make. It was only after the customers bought the software that they realized their need for this type of information.

This practice of "information hiding" is subtly woven into the business models of commercial software vendors but it is not advocated for open source companies. The community could rebel if a company is not meeting their needs for technical information.

Related to this is a business model dilemma faced by open source companies vis-à-vis technical support and their mailing lists and community forums. On one hand, they want their communities to thrive and to actively share information. And it's important that the company's employees participate in this process, otherwise, the community could take on a life of its own and decide that they do not need the company. On the other hand, if the company spends too much of its resources to answer technical questions to please the community, why would anyone buy support? There would be no need to buy support as users can just get all of their questions answered for free. Once you start following a particular policy of what types of questions to answer for free, the community becomes conditioned to it and if you later decide to change course, you risk alienating the people whose loyalty and trust you are striving to keep. Most open source companies ultimately strike a delicate balance by providing tools such as knowledgebases and online documentation that enable users to help themselves, while charging for situations where users request individual attention.

Being Honest
Another fundamental business model question for open source companies involves the license for their software. Although there are a few predominant licenses such as Berkeley Software Distribution (BSD), GNU General Public License (GPL) and the Mozilla Public License (MPL), there are hundreds of other licenses and derivatives of these core licenses. Related to this, there is virtually no case law to support the legality of the terms in many of these licenses (sort of like the wild, wild west).

The choice of which license to use for an open source project and company is of utmost consideration for the company's business model. Choosing which license is best for your project is beyond the scope of this article. However, there are many good resources that discuss the pros and cons of different licenses. It is also advised to consult with an experienced attorney who specializes in open source licenses.

That said, I'd like to share our own recent experience, as an example of licensing considerations that open source companies face and how it affects their business model.

Until recently, Funambol used the GPL. This enabled people the use of the software pretty freely, i.e., if they were just using it for internal use, they did not need to return anything to the community. If they distributed the software to the public, they were required to make their entire software available to the community or buy a commercial license that relaxed this provision. This is all in keeping with the community spirit of enhancing the code for everyone's benefit.

A situation we ran into recently involved the trend of delivering software as a service. In brief, some people were exploiting a loophole in the GPL relating to the term "distribution." Because they were distributing their service over the Internet instead of via a CD, they thought that they were exempt from the requirement to give code changes back to the community. We recently introduced a new type of license called the Honest Public License (HPL) that is equivalent to GPL but that says that software delivered as a service over the Internet is just another form of software distribution and therefore the company has to either make its code changes available to the community or pay for a license. This is a change that many other open source companies have applauded and is currently part of the latest draft of GPLv3. Our hope is that the final version of GPLv3 retains this language so that HPL will be unnecessary. This is just an example of how the choice of license can greatly impact your business model so that you need to choose your licensing carefully.

Customer Balancing Act: Quality and Usability Are Key
Lastly, being an open source company that appeals initially to developers has other ramifications for a company's business model. Consider the quality and documentation of your software. It's one thing if the target user for software is developers. They may be forgiving in the face of errors, since they can fix code, or not mind about sparse documentation, because they can read the code and figure things out (in fact, for certain projects, it is a badge of honor to decipher complex code and be one of the few people who understand how code works). Now consider that you want to sell this same software to an audience of enterprise IT managers and corporate developers. These are people used to working with highly polished, documented and tested commercial software. They are less likely to be sympathetic with software that is buggy or appears unfinished. And it is pretty likely that open source developers may not care that much about polishing the software for corporate users.

Hence, a major tightrope challenge is how much effort you put into polishing the software for a commercial audience. As with the other decisions faced by open source companies, there are not universally right or wrong answers, you need to weigh the pros and cons for each situation. In some cases, it might take longer or require additional resources because of the need to satisfy multiple constituencies, which may run counter to the belief that open source software is faster and cheaper.

That said, there is little doubt that an open source company that makes it business model decisions with its community interests in mind all the time stands a much greater chance of being embraced by its community, which in turn will often benefit commercial customers alike. The trick is keeping the right balance on the tightrope.