Previous Table of Contents Up Next Lack of ResourcesThe underlying cause of a number of the mistakes we have been discussing is a lack of resources, most notably people to work on some necessary aspect of your project. These people can be employees of your company who are assigned to work on your project, or they can be volunteers, including employees of other companies. Many projects do not have anyone assigned to be a community manager or coordinator. That can compound any resource problems because the community coordinator is the person who recruits volunteers from the community to help out. For a smaller project, this can be done by the project owner, whereas for bigger projects, it might be part of the product manager's job. For large projects, it can become a full-time job. The most common reason a project's website becomes stale is that no one has time to update it. Outside contributions can get ignored when module owners are too busy. Someone needs to write the internal documentation needed to orient potential contributors. Make sure that you don't let critical tasks remain undone: Assign an employee of your company or find an outside volunteer. One of the primary reasons to do an open-source project is to benefit from feedback from outside your company. If you do not have the resources to take advantage of this community feedback, then you are missing out on a major opportunity. Many company-sponsored open-source projects suffer from this problem by having inflexible plans made without consulting their communities. In addition to not acting on the good ideas suggested by your community members, you alienate them by ignoring what they are trying to tell you. They will stop wasting their time trying to interact with you and devote their energy elsewhere. A related problem is using the wrong resources. An open-source project is a development effort that exploits continuous design but with further opportunities for marketing-related and other strategic efforts. Nevertheless, the heart of the activity is development with development goals and practices. Things can go wrong if an organization other than engineering or development is the home for open-source projects and open-source oversight. For example, sometimes a company will determine that it needs to build a community of developers for some strategic purpose such as executing on a "developer capture" program designed to lure more developers into the company's camp. Because this is a marketing activity, it might seem natural to locate oversight in a marketing group, so that, for example, measurements of progress and of the nature of the developers captured can be made. However, a marketing group is unlikely to know enough about software development to oversee the community, nor is it likely to have a reason to care about ongoing software development once the developers have been "captured."
|
|||
|