Symptoms[]
Company founders instinctively feel that they should own products their companies build. So when they start free software projects, their entire strategy revolves around owning all the copyrights, and being able to dictate what is included in the software.
Command and control
The logic is impeccable, and the reasons are many: This software is the basis for our reputation with our users, so we must defend our trademarks and ensure quality. We have a responsibility to ensure only well tested features ship. We may need to change the license in the future. We need to ensure we can offer indemnification to clients. We may want to use a dual licencing strategy to generate revenues - and someone's gotta pay for the product to get built. And "taking care of the community" costs time & money that we don't have when we're driving to get a product out the door.
This is all fine, as far as it goes. But this "Command & Control" mentality generally results in a number of things which are very harmful for growing a contributor community. Copyright assignment & contributor agreements raise the barrier to entry for participation, roadmaps which are not published, or which don't leave any room for external participants, Most of the work gets done around the water cooler, because the people you pay are the people you can control. Trademark defense is used as a justification to prevent forking of project code.
The few volunteer developers you do get find that they're being undermined by "Big Show" announcements, professional developers who land big features no-one has ever heard of with no public discussion, and a general impression that they are outside the walled city, waiting for a portcullis to open & a drawbridge to lower so that they can come inside.
The end result is like trying to grow crystals when there are too many vibrations: you never get a seed that grows into a useful, healthy community. You are reinforcing your own prediction that you can't rely on the community, by not giving anyone outside your company a good excuse to work with you.
Examples[]
Unity from Canonical, a project which requires copyright assignment to the company, has 10 active developers, all employed by Canonical.
Sun struggled for many years to grow contributor agreements around OpenOffice.org, OpenSolaris and Java. They were often criticised for their desire to control aspects of the community projects.
Treatment[]
Companies releasing open source software can exchange influence for control by recognising that being the founder already affords them enormous respect & a position of authority in a project. Copyright assignment is usually unnecessary to the achievement of business objectives, and is often harmful to the achievement of community goals.
Teams can apply the same treatments as for the water cooler anti-pattern - working in glasshouses, in public, to allow people outside your company understand why design choices are made and anticipate opportunities to participate.
The Big Show type announcement is mostly incompatible with community development. As a company, you are stuck between a rock and a hard place here - either you announce secret plans early, before you start working on them, to allow community participation, or you announce them late, with a code drop, when it is too late to help. In the former situation, you end up disappointing potential users and press by announcing something months or years before it is available.
A half-way house is to start working on functionality in a low-key way in community forums, and do the press release & big splash announcement when the feature is ready - most people in your user community & the trade press will not notice that the feature was already on your roadmap a year earlier.
Related patterns[]
Water cooler and The Big Show are often seen in projects with a Command & Control structure. Companies who think of their developer community as primarily the people who are paid to work on the product also tend to flip the Day One commit bit.