Previous    Table of Contents    Up    Next

8. How To Build Momentum

The previous chapters of this book have described all the elements that go into creating and running an open-source project. In this chapter, we discuss some things you can do to increase your project's chances for success. This builds on the material in the section Building a Community in Chapter 6, which covers the basic things to do. The next chapter focuses on what not to do based on lessons learned from the failures and mistakes we've observed in various open-source projects.

The ideas in this chapter apply to any open-source project; however, we want to emphasize that a company engaging in an open-source project has many additional resources that can be used to further the project in ways that are not available to individual volunteers. In addition to developers, a company also employs technical writers, user-interface experts, graphic artists, website designers, technology evangelists, marketing people, project managers, and people with other skills, all of whom can help with different aspects of the project. Once they understand the open-source process, these folks can make major contributions to help the project become a success. All the activities that your company does to support a proprietary product--marketing, advertising, support, and training--are also needed for an open-source project.

As you read over this chapter, remember what your business goals are and focus on how to achieve them. Creating a successful open-source project is only part of your strategy. As the project grows and develops, it will take on a life of its own. You need to balance the needs of the open-source community against your business goals. For the most part, they should be aligned toward a common purpose, and developers from both inside and outside of your company will work together to achieve them. Where they are orthogonal, you should let the community proceed on its own. If they are opposed, you need to be very upfront about communicating your plans and reach some agreement that does not alienate or frustrate your community.

For example, one of the business goals of the NetBeans project was for Sun to sell proprietary modules that added functionality to the basic NetBeans IDE. Developing similar modules as open source in NetBeans would undermine this goal because the functionality would then be available for free. However, outside developers have every right to expect that any useful modules they create can become part of NetBeans. So the decision was made that any module could be developed for NetBeans. It also was decided that when a NetBeans module duplicated the functionality of one of Sun's proprietary modules the Sun version would be open sourced. In this way, the functionality level of NetBeans would continually go up, which would be good for the health of the project. Sun could make this decision because the Sun engineers were confident that they would always be able to develop new proprietary modules that Sun could sell, so they did not need to hold tightly to their existing ones.

Marketing Your Project

Focus on Your Users and Contributors

Community Outreach

Harvesting Innovation

Welcome the Unexpected