Problems You Can Expect to Encounter

Getting Engagement

The first problem you may face when you start up your open-source project is that no one seems to care about it--no potential users download your application to try it out; perhaps no one even visits your project's website. If so, you need to publicize your project, telling people how and why it helps them. See the section on Marketing Your Project in Chapter 8 for suggestions on ways to do this.

Another problem you may encounter is that once you start getting users, only a few bug reports or contributions are submitted. People are downloading your application and, you hope, using it, but they are not providing the feedback or improvements you had hoped for. It may be because it just takes time for a community to develop, but it also may be that you are discouraging outside participation. Some things that you can do to increase participation are described in the section Focus on Your Users and Contributors in Chapter 8.

A third problem you may see is that many user questions posted to your project's mailing lists go unanswered. If outside individuals are posting only questions to your mailing lists and your team is answering all of them, you will quickly become overwhelmed trying to answer everybody. When you start up the open-source project, tell your developers to use the rule of delaying answering a posted question for a day or two. This will encourage your users to answer them. If a question has not been not answered after a day or two, then one of your developers should answer it. Typically, the community manager is the one to answer such questions, but make sure those you assign are capable of answering the more difficult questions asked by your intermediate and advanced community members--these members, knowing their questions will be answered by one of the experts you've assigned, will have a reason to stay on the list, and they will be just the ones to provide answers to the easier queries. Check the attitude expressed in the messages your team posts: Is it arrogant? Does your team embarrass people when they are wrong? You need to make the mailing list a safe place for people to participate.

It is very important to build up a community of givers rather than takers. Open source is very much a gift economy. The more personally connected your team members are with other individuals in the community and the more they are perceived as giving to and caring about the community, the greater will be the community involvement and participation in the project. Conversely, if your developers act as if they are just doing their jobs, then do not expect much in the way of outside volunteers or for a community to develop--at best you will have a user group.

Plays Well with Others

Software developers often have strong opinions and are not shy about expressing them. Some might even be accused of lacking in social skills. When they interact, sparks can fly and lots of unproductive flaming can result. In every open-source project, there will often be major differences of opinion on what is the best architecture or technical solution to any given problem. Too many battles can split a community, causing some developers to leave to start a competing project. To avoid this fate for your project, it is important that your developers learn to help arbitrate any flame wars that occur. Even when they disagree with some community member, they need to keep the conversation civil and focus the community on its common goals. Make sure people feel they are being heard and that their viewpoint is seen as a positive contribution to the project even if it is not the direction chosen. Figure out a way to explicitly recognize and reward those of your team who douse flames well.

A related problem is that some discussions never seem to resolve: Various viewpoints get expressed, but no solution is agreed on. In some projects, the project founder or a module owner plays the role of final decision maker. In other projects, there is no one individual in charge. For those other projects, each issue needs to have a person assigned to bring it to conclusion--often this is the person who brought up the issue or the one who will undertake implementing whatever solution is chosen. It might also be a person with good project management skills, who can listen to what developers are saying. This person needs to follow-up on each issue raised during the discussion, get a sense of how the community feels about each, and summarize matters when the discussion winds down or when nothing new is being said. The summary should indicate what was decided and who will do any associated work to implement it.

The decision about an issue can also falter because only a few people participate in the discussion. It might be necessary to solicit the opinions of specific community members who are knowledgeable on the particular issue. Lack of discussion may also indicate that the community does not consider the issue to be important, and so the appropriate decision might be to do nothing for now.

Sometimes there will be lots of noise on the project's mailing lists, often by people who think they know more than they actually do or who have an extreme viewpoint--noise in the form of extended discussion on how to approach a particular problem or a new idea about what to add or a direction to go. There will always be some noise like this on the lists, but too much can drive valued community members away. However, it's important to consider whether some discussion really is noise or whether it is important information that differs from the prejudices of the main project developers--sometimes it is hard to tell the difference. Often the best solution is to suggest that those in favor of the new idea should create a new subproject and implement a prototype. This at least moves the discussion to another list and your community might be pleasantly surprised when they get to see the idea put into practice. As for those few folks who continue to send flames, you may need to send them a private message asking them what's going on and to please tone it down--sometimes they don't realize that they are acting inappropriately.

Managing community expectations is another common problem. No matter how much you do, you can count on people requesting additional features--in fact you want them to. Some of these requests will be for things that everyone agrees would be great, whereas others may be more questionable or not fit with the project's main direction. In any case, your company has only so many employees who can work on your project, so there will always be more than you can do. It is very important that you establish a community of peers where it is taken for granted that anyone can and does contribute to the project. In such a community, the person who proposes a new feature is a logical choice for who should implement it. Although some open-source projects adopt the attitude that anyone who proposes a change or feature must "show me the code," you shouldn't fall prey to it. Sometimes a gifted designer or someone who understands the user community very well is not a gifted coder, and you should encourage outside developers to work with such people. What you do not want is a community where everyone expects that all significant work will be done only by your company. When there is a feature that you do not wish to have your employees work on, you want the community's energies directed at implementing the feature itself, not at trying to convince you to do so.

Dealing with Your Own Company

Sometimes it's not just the community outside your company that insists on telling you what to do. Sometimes other groups inside your own company demand that you add features for them that you either do not have the resources to do or that clash with the publicly stated road map of your project. The more you can encourage other parts of your company to actively participate through the open-source process, the better. Once other groups learn that they can submit bug fixes and new features directly, they will understand that they can control their own schedules and not be dependent on your group. This is the same form of risk reduction that a company enjoys when it has a source-code escrow agreement with a supplier or it uses an open-source solution and the original supplier or support company is unresponsive or goes out of business: The source code can be fixed and improved without the intercession of the original development group. In this way, open source can reduce risks for other parts of your company.

If your current managers have problems resolving disputes among your developers, then making your project open source can make things worse. As already mentioned, the open-source method of making decisions via public discussion on project mailing lists often does not reach a clear consensus. If your own developers do not agree with the direction the project is taking, they can air their objections in the public discussion and use the ensuing uncertainty to block others from taking action. It is important that your developers be able to express themselves freely on the project mailing lists, but you do not want them using those discussions to further their private agendas. This can sometimes be a tough call, and it requires that your project managers be willing to step in when necessary and make decisions about what your company's developers should be working on. An example of this problem that we've seen occur is when a developer who does not want to implement what a user-interface designer has proposed uses disagreements with the proposal on the mailing lists as a reason to do whatever that developer prefers. In a traditional proprietary project, the developer would not have a choice, but would need to implement what the UI expert thought best.

Another common problem occurs when there is a change in management in your company and your new management doesn't understand open source. If this happens, you need to immediately start to educate them about open source and make it clear how your use of open source helps your company. If your old manager can help explain why open source makes sense, so much the better. A failure on your part to sell your new management on the value of open source can have disastrous consequences, both when resource decisions need to be made and when you and your project come up for review.

Contributing to Other Projects

The last problem we consider here is you as an individual having trouble getting your contributions accepted when you are participating in an open-source project that is run by someone else. You've fixed a major bug or written some nifty new feature, but you cannot get the open-source project to accept it. It can be very frustrating when you are trying to help, but are being ignored.

There are several reasons why this may be the case. The first is that the community might not know you. If this is your first contribution, then people will be wondering who you are and why should they pay any attention to what you say. It is very important that you build up your reputation with the community by helping to fix small bugs and participating in discussions. Contributions that show people that you are competent and that affirm that you share in the project's goals will give you standing in the community. Only then will people be willing to listen to you when you make suggestions that go beyond the current project road map. You and the rest of your team may be the authorities within your company, but unless you are also world famous, you will need to establish a track record through your participation in the open-source project. It's not just a question of your competency, but also one of trust. This is especially important because companies are often viewed suspiciously and many will assume your company is trying somehow through you to rip off the work done by the open-source community. You need to demonstrate that you, as an individual, are someone the community can trust.

Another reason your contribution may not be accepted is that your proposed solution is not seen by the community as adding any value. This may be because you are concerned about a different set of issues--for example, you may be extending the software to work in a complex enterprise setting, whereas the project's focus is on an individual using a single machine; or you may be interested in making the software more usable by novices, whereas the community is mostly expert power users. It's up to you to convince the community members--or at least the relevant module owner--that what you are proposing has value. In any such discussion, you should listen carefully to any objections raised by the community. It is very likely that you will need to modify your proposed solution to take the community's concerns into account. You should start this dialog as soon as you know that you need to fix some bug or add some feature, well before you write any code. If you wait until after you have all the code written and then surprise the community with it, you will probably be the one surprised.

For more discussion see the section Getting Your Contributions Accepted in Chapter 6.

You may find that the project or module owner isn't responding to your email messages. Remember that a lot of open-source developers are volunteers, so they may be busy with their real jobs or other work, they might be on vacation, or they may be temporarily burned out on open source. By looking at the traffic on the project's mailing lists and in the mail archives, you should be able to determine whether the project owner is ignoring just you or is simply not currently active at all. Also, as previously mentioned, if no one knows who you are, then on a busy mailing list your comments will be easy to overlook, especially if they are on a topic far from the project's current focus.