In order to understand professional open source companies there certain facts about open source that need to be understood.
Free means Freedom Not 'Free Stuff'
Open source is not free. In 1998 the term 'open source' was coined to replace the term 'free software' because many people assumed 'free' to mean 'zero cost' whereas it was always intended to mean 'freedom'. If you consider the barriers to adoption of open source listed above it becomes clear that the notion of 'free stuff' is false. It is true that an organization could use open source software and support itself by hiring technical staff with the necessary skills to:
In addition to the costs above there are also risks to be managed. In fact if you look at the commonly listed barriers to the adoption of open source software you will find that most of them are related to some kind of risk and not to any kind of cost. It is difficult for most organizations to manage all of these risks themselves: the number of people and the range of skills required to do so is prohibitive. For small organizations or low-risk projects these risks can be tolerated but for larger projects risk management is a significant issue.
This leads to the basic rational of professional open source: to provide organizations with an alternative to 'going it alone' with open source.
Principle of 'Openness'
Accepting feedback through a web page and providing mechanisms for people to report defects is one thing. Allowing everyone else to see that feedback and all those defects is another, much more uncomfortable, step. Allowing everyone to see the source code so they can review it and try it is also an act of faith. Providing a public forum where people can openly criticize and contribute to the design and implementation of the software is another act of faith. These are difficult behaviors for a proprietary organization to accept but open source projects rely on them. If the project administrators do not provide mechanisms for people to communicate openly amongst themselves there can be no community.
The availability of the design documents and source code enables the community to provide peer reviews and to use the software for their purposes and provide feedback on the quality.
Principle of 'Transparency'
Transparency is the ability of the community to see what's going on. This involves:
Transparency and openness are not the same thing. A glass door is transparent but whether it is open or not is a different matter. Transparency is the ability to witness the inner workings, openness is the letting outsiders 'in' so they can participate.
Principle of 'Early and Often'
This is the philosophy of making information available in its earliest drafts and updating it often. This includes, but is not limited to, the source code of the software. Zipped archives of the source code are available for every open source project. Many projects go further and have a public repository where the current code is always available. As the developers change the source code and check it in, it is available to anyone who wants to review it or use it.
The principles of open source compound and combine together. Each one is a leap of faith.
In order to be successful all the principles must be observed: merely letting someone view source code, or giving someone a free evaluation license does not have the same disruptive power of the open source model. The tendency of the open source model to resolve design defects early in the software development cycle only occurs if all three principles are applied.
Expectation of 'Community'
Every generation grows up with a new set of expectations. For example my parents had the expectation that they needed to buy encyclopedias if they wanted access to reference knowledge at home. I grew up with the expectation that I could get Encarta(tm) on a CD and later that I could search the Internet. My son is growing up in the Web 2.0 era where he can participate by submitting Wikipedia entries.
When it comes to open source the web site, source code, roadmap, defect tracking system, and forums are the 'project' and the community participates in the project. The fact that the source code and roadmap are available is a result of 'openness'. The fact that the defect tracking system and forums are available is a result of transparency. The fact that the design and initial code is available is a result of 'early and often'. It is these principles and the results of using them that ultimately attract and retain the community.
The community is a byproduct of the project. The project is a byproduct of the open source principles.
Participants in open source have an expectation of a community and the development model and professional open source company relies on it.