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.
Ian Skerrett 
I have neither complaint nor argument with what you have written here. Copyright is just one dimension, along with licenses and the question of control.
Me likey Eclipse.
Agree with every point. Here as an actual BAD example of practices for an Open Development Community: http://www.jroller.com/andyl/entry/how_open_is_mercurialeclipse .
I think on of the reasons why Linux is so successful is actually the GPL, nobody can take Linux and improve it without contributing back. Therefore I would argue that every license has its merits.
EPL is definitely business friendly. One thing that seems to be the case in Eclipse is that it appears that most individual Eclipse projects are driven by one company which founds the activities. Maybe this is connected to the license?
@lars
I think Linux is successful because a lot of people wanted an alternative operating system that was widely adopted. If this was not the case, then very few people would have been motivated to even improve Linux. I am not a big believer that force contributions back is the reason for success. Good contributions come from motivated people wanting to create great technology, not due to a licensing issue.
Not sure I get your connection between EPL and single company projects? I’d also think most of our successful projects have multiple companies involved.
@Ian: About Linux I’m not so sure. BSD is available under a very permissive license but is not growing as strong as. Apple also took BSD and adjusted it to its needs without contributing back.
Webkit is also (partially under LGPL) and AFAIK Apple was forced to contribute their changes back to it.
Wrt. Eclipse I believe highly visual parts are dominated by one company. For example Xtext == Itemis, Eclipse Core + UI ~= IBM, RAP == EclipseSource, PHP ~= Zend.
I’m not saying this is necessary bad but I also thing that each license has its merrits.
@Lars Not really understanding your parallel of EPL to one company dominating a project. I agree some Eclipse projects are dominated by one company but some are not, such as WTP, CDT, CDO. I think the multi-company aspect is more to deal with the adopter community of a project. Lots of adopers leads to more contributions coming back.