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:

Evaluate and select the most suitable open source software or software distribution.
Integrate and embed the open source software into internal systems.
Fix any critical defects that are found.
Decide which patches and releases to migrate to and ensure migrations between versions are free from problems.
Participate in the communities to ensure the direction that the software is taking suits the organization.
Train any users or new technical staff.

Organizations have the freedom to do all these things but they should not consider fulfilling these needs to be of zero cost.
If you accept that open source software is not a zero cost solution you must then accept that these costs can occur in the form of time (internal man hours) or money (given to some external organization) or both.

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:

A published road map so they know where the administrators plan to take the project.
A public defect tracking system so they can report and review defects.
Published design documentation.
Communication about schedules and hurdles.

Without transparency it is hard to grow a community.

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.

Next - The Beekeeper Model

Browser not supported