My recent blog post Changing Nature of Open Source Companies discusses a 451 Group report that describes how corporate open source strategies have been evolving through four different stages. Most companies are now looking at creating and participating in an open development community. As a reminder, the four stages describe in the 451 Group report are:
1. Software developed by communities of individuals
2. Vendors begin to engage with existing open source communities
3. Vendor-dominated open source development and distribution projects
4. Corporate-dominated open source development communities
If companies are moving in this direction, what are the strategies and best practices they should follow. Based on my experience, I see there are 5 key things companies should consider when trying create a successful open development community.
Top 5 Best Practices
1. Engage a wider community, use a permissive (ASL) or weak copyleft license (EPL). The goal of a successful open development community should be that everyone is welcome to participate as a user, adopter or contributor. Unfortunately, the choice of an open source license can limit participation, in particular licensing a project under the GPL can limit the number of organization willing to participate. For example, companies that want use the technology in commercial licensed product will be excluded due to the terms of the GPL. Using a permissive license, like the Apache Software License (ASL), or a weak copyleft license, like the Eclipse Public License(EPL), makes it easier for a wider range of companies to engage.
2. Earn the trust of the community, don’t require copyright assignment. In vendor dominated open source projects, contributors are often required to assign the copyright of their contribution to the vendor. This allows the vendor to adopt alternative licensing strategies, such as dual licensing, which may create a revenue stream unique to that company.
Successful open development communities don’t require copyright assignments to a single for-profit company. This is because organizations and individuals want to participate as equals in a community. If one entity is aggregating a special right, in this case copyright to the code, it creates a two tiered system. Copyright to contributions should be retained by the contributor or a license granted to a not-for-profit Foundation.
3. Be truly open, develop in the open. In an open development community, the development teams need to truly work in the open. They need to be using public issue trackers, public code repositories, public build systems and not be developing behind a firewall and once a month doing a code commit to a public code repository.
The development team also needs to make sure updated project plans are published and technical discussions occur in a public forum, not a hallway. The development team needs to start believing they are part of a large community, not a traditional vendor oriented development team.
4. Have a clear policy on trademarks. The organization that controls the trademark for the project name can ultimately decide how the name is used. For instance, who can use the trademark in a commercial product name, a company name, a service or even a conference name. In the case of a fork, the organization that controls the trademark controls where the project name can be used.
Successful open development communities define trademark guidelines that describe how the trademarks can and can’t be used. The trademark guidelines need to allow all organizations the same rights and privileges.
5. Implement a vendor neutral governance structure. Successful communities have well defined rules for decision making. How are decisions made on admitting new committers, who decides the project roadmap and project release schedules, how are technical architecture decisions made, etc. Also, what is the process to change the rules, strategy and purpose of the community. All communities need to adapt so who gets to make these decisions.
A successful open development community has these rules written down in some form of governance document. This allows everyone to know what to expect. A truly vendor neutral governance structure would not allow any one organization extra decision making influence within the community.
Bonus Best Practice
As a reminder, a project that creates something really useful and has high quality code is definitely the starting point for any successful open source project. 
Vendors that participate in successful open development communities win by giving up control. This can be difficult for a lot of companies but remember ‘if you love something, set it free’
End notes, I would definitely recommend reading the 451 Group research paper on Control and Community. It is really good and if your company is seriously looking at an open source strategy you need to read it and understand it.
Also, these recommendations are targeted at companies interested in developing open development communities. A lot of these recommendations apply to any open source projects. For simplicity of text, I have focused on the corporate participation.
