Previous    Table of Contents    Up    Next

Ending an Open-Source Project

Open-source projects have a natural life cycle. They may start out slowly and then have a long period of growth when many new features are added and bugs fixed. Eventually, they can mature and go into a maintenance phase when people still use the software, but no further major development is done. As your project matures and you achieve your main business goals for it, you may want to reallocate resources to other efforts. Also, a change in your company's situation might force a decrease in its level of involvement. It is natural for the founder of an open-source project to leave in order to move on to other interests. However, this does not necessarily mean just abandoning the project.

Right from the start of your project, you need to make it a practice to encourage community members to increase their participation. You should recruit active outside developers into the core team, giving them as much responsibility as they will take on. Each module owner should identify another developer who can take over as the new maintainer for the module if need be. For example, each module in Mozilla has an owner and one or more peers who can also approve code for check-in into the module; a peer is an obvious choice for replacing the current module owner. Involving outside developers in the running of your project early on is healthy for your project and creates a pool of people that you can turn the project over to should you need to.If your company decides to reduce or end its involvement in an open-source project, there are certain steps you need to take in order to assure a smooth transition and to avoid creating bad feelings toward your company. This is all very similar to how your company handles the end of life of its products in order not to antagonize its customers. Your company probably has a special process to approve ending a product. It should have a similar approval process for ending or decreasing participation in an open-source project that it has sponsored.

As soon as the possibility that the company may need to decrease its level of involvement with the project arises, you need to plan out how to disengage. In your internal discussions, you may need to remind your managers and others that the company must not abruptly end its involvement--they need to understand that it will probably take several months to ramp down and turn the project over to the community.

It is important that you announce your company's intentions to your community as soon as possible. You want them to hear it from you, not through rumors or an article in the press. Remember that what you do here may hurt the company's reputation, making it harder to sponsor or participate in other open-source projects in the future.

If your company is currently paying for your project's website and it plans to stop doing so, then you need to work with your community to find a new home for it. Possibly one of your community members might be able to take over the hosting of it, or you may need to make use of one of the free open-source hosting services, such as SourceForge. You should help migrate over all of the website contents, CVS trees, bug databases, email archives, and other community documents. Be sure that the source code does not disappear when your company stops its support because your company may have a legal obligation to make sure the source code continues to be available for some specified time period. For example, the GPL requires the source code to be available for 3 years after the last release was distributed.

You need to decide the level of future involvement your company wishes to have with the project, if any. This includes whether you want to encourage your developers to continue working on it as part of their jobs or on their own time if they so choose. For example, will you permit your developers to take time to answer questions about the source code that only they may be able to answer?

How your company ends its involvement will leave a lasting impression. By doing things right, your company will be remembered for generously contributing its efforts to make the project a success. If your company just abandons the project, then it will be thought of as a company that doesn't care about open source and that is not a good partner.

Innovation Happens Elsewhere
Ron Goldman & Richard P. Gabriel
Send your comments to us at IHE at

Previous    Table of Contents    Up    Next