Ian is the Director of Marketing for the Eclipse Foundation and live in Ottawa, Canada. Ian is a DZone MVB and is not an employee of DZone and has posted 163 posts at DZone. You can read more from them at their website. View Full User Profile

Top 5 Best Practices for a Successful Open Development Community

11.19.2010
| 10583 views |
  • submit to reddit

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.

From http://ianskerrett.wordpress.com/2010/11/18/top-5-best-practices-for-a-successful-open-development-community/

Published at DZone with permission of Ian Skerrett, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andrew McVeigh replied on Fri, 2010/11/19 - 8:45am

Open source is a curious thing.  Although there are lots of open source projects, they often have an agenda. And what is an agenda to one group is simply a reason for doing open source to another.

So, although many projects are technically completely open from a licensing perspective, there are a lot of other ways to control things that preserve the full illusion of openness but restrict openness to only one part of the community.  Some examples: placing new releases in a private repository and keeping the public repository slightly old and incomplete for handset vendors (android), suppressing tags from the public repository to avoid community builds and patch releases (springsource attempted this), controlling and restricting all the committers of a project so you can claim to be the only company to be able to support an open source stack (many projects), viciously protect the trademark to build up a brand (JBoss).  ...or closer to home, using open source as a strategic way to commoditise and reduce vendor competition in a market whilst delivering great value to end users (Eclipse).

What i'm saying is "open isn't necessarily without agenda" even if technically it's completely open and with good intentions.

Igor Laera replied on Fri, 2010/11/19 - 12:12pm

 

The true open projects are the ones they involved parties don't really care if they
continue to use/work/benefit on that project forever.

If you work on a trademarked appserver and try to monetize it with a larger opensource
involvement its simply a different model - as for example - producing a opensource desktop
publishing software where everybody can use it and make additions to it. You might only
get a few support contracts, but this is how it is. I doubt people going this route really
believe that they can finance their operation this way, it's more an "agenda"-like approach.

I don't fully accept the conclusion of the report, that every product is full opensource-able and
grows by the community approach. For example, there were only few external contributions
to the old openoffice codebase. Maybe this changes fundamentally by the LibreOffice-Fork,
but I doubt it. It's simply harder to get into obscure 90ties C++ code then the next PHP
based webgroupwarewikiforum fad/hype ;)

Finding the right concept for a project/product is quite hard in this times. Such articles show
how other projects "do it" - but the decision process is still complex.

Martijn Verburg replied on Sat, 2010/11/20 - 9:50am

Of course the wisdom of Karl Fogel should not be ignored: http://www.producingoss.org

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.