Community Outreach

Establishing Credibility with the Open-Source Crowd

Beyond the day-to-day activities of your project, there are some other things you can do to establish better credibility with the larger open-source community. The bigger and more visible your project is, the more important it is for people working on other open-source projects to see you as being part of this larger open-source community.

First, it will help if you are using a license that has been blessed by the more well-known spokespeople for open source, such as Richard Stallman, Tim O'Reilly, Bruce Perens, and Eric Raymond. If your project uses an OSI-certified open-source license such as BSD, Mozilla, or the GNU GPL, then these spokespeople will be able to go on record as saying your project is true open source and a Good Thing. If your project is using a proprietary or shared source license, they and the press will be sure to point out that your project is not open source. This issue arose with Sun's Jini project, which uses the Sun Community Source License (SCSL)--even though Sun was quite clear in stating that it was creating a gated community and not trying to do true open source, the press and some open-source pundits kept saying, "Yes, but it's not open source." This deflected attention from the Jini technology and slowed down the growth of the project around it.

Second, you should establish strong, positive connections with other open-source projects. If your project uses tools or modules developed by other open-source projects or your project produces tools or modules that other open-source projects could benefit from, then not only should you be involved with these other projects, but you should try to entwine their projects and yours as much as possible. An ideal situation is for your project to be part of the planning process--for future features and the timing of releases--for those other projects. The OpenOffice project started with the intent to integrate its office productivity suite with the GNOME desktop, so it became involved in the GNOME community, contributing code and bug fixes back to the GNOME project. As the collaboration deepened, technologies and components from each project became part of the other, so that OpenOffice can be said to be deeply embedded into GNOME. The more your project is seen as not only supporting but deeply integrated with other open-source efforts, the more your project--and thus your company--will be considered a good member of the larger open-source community.

You should also establish dialogs with open-source developers not involved with your project. Have your internal developers both read and post to places such as Slashdot.1 Encourage them to start individual weblogs. The more individuals from your company that people see participating in open-source forums--especially when their email addresses include your company's domain name--the harder it will be for them to see your company as a large faceless corporation. It is fine for your company's developers to express whatever views they have, but they should strive for some restraint and avoid too much flaming. As mentioned in the section on Posting Etiquette (Chapter 6), they need to remember that even though they are posting as individuals, people will read their notes as being your company's official policy. When your company's actions are attacked, they should wait a bit to first give outside people a chance to defend your company--statements from people not employed by your company are more effective than statements from employees. Of course, if the criticism is valid, your developers should immediately acknowledge it and fix things.