Open Source Transitions - Trial By Fire 1

Part one of a continuing series on critical challenges that are unique to open source projects and businesses.

In the beginning, an open source project is created by a single developer, a small group, or a startup. The initial creators write the code, put it out there, and hope that others will adopt it. In the meantime, they do everything from designing new features, writing code, reviewing and committing them, fixing bugs, writing documentation, and providing support on mailing lists.

Unfortunately, it usually ends here. Most open source projects languish and are eventually abandoned by their creators.

Fortunately, though, this open source project succeeds. Many users download it and start working with it. The mailing lists get busy. After a while, a community develops around the project. The original creators bask in the glory of their successful project and are (hopefully) successful themselves from it, selling everything from books to consulting services to value-added commercial products.

Then, the project comes to a transition point. As community members become more involved with the project, they are ready to play a bigger role. They start planning and developing new features themselves, writing their own documentations and how-to guides, answering emails on the mailing lists, and so on.

What happens now?

At a minimum, the project creators need to pull back from their earlier hands-on roles. They need to let others do the day-to-day work of fixing bugs, writing documentation, and providing support. At the same time, they must still shepherd the project. Only they can set the right direction for the project. They still must invest in strategic development to push the project along. They must maintain high standards for the documentation, code, and support. And they must do all this while continuing to build and nurture the community.

This is not easy to do. It is very similar to the transition that most entrepreneurs face as their businesses grow and they must relinquish day-to-day tasks to focus on the bigger picture. Many entrepreneurs can't or doesn't want to do this and eventually move on.

This transition is even harder when the original creators have built businesses around their project. They may be selling support services, documentation, or commercially-licensed versions with premium features based on their open source project. What happens when the community starts to create free (or nearly free) alternatives to the founders' offerings? Here are some options:

1. Squash the competition. The knee jerk reaction. Use your position as the maintainer of the project to shut out competing efforts. Or, spread FUD around community efforts, with statements like "It's so great to see all this involvement, but..." But is this productive? Should you really be expending valuable resources to create something that would otherwise be free?
   
2. Keep competing offerings. Inertia at work. Even though the community has produced a free alternative, you continue to spend money to develop, maintain, and sell your version. Hopefully, you can leverage your position in the community (essentially, your brand) to do so. You're still paying for something that should be free, though. And if your project continues to be successful, the community will eventually grow large enough to overtake you. In that case, your expensive but inferior offerings could actually end up damaging your brand. (This has happened to a major vendor whose name I will not mention here.)
   
3. Replace your offering with the community's. Like Gordon Gekko said in Wall Street, "Never get emotional about a stock." Once better code, features, documentation, or support become available from the community, drop yours and adopt its. This would, however, significantly affect your ROI. It may also embolden others to start competing with you.
4. Give back to your community. Periodically gift proprietary code and documentation back to the community. You can create goodwill, enhance your brand, and eliminate potential competitors. But then how do you convince someone to continue to pay for proprietary offerings when, sooner or later, you might make it free?

The challenges in managing this transition successfully are:

1. Can the original creators of the project let go of their own ego and emotions and let others play a bigger role?
2. Can they encourage the right people to get involved? Can they filter out weak ideas while avoiding a fork in the project?
3. Can they repeatedly re-focus their resources correctly on core versus non-core competencies? Can they successfully extract value from their core strengths, while getting others to produce non-core offerings?

This is not an easy transition for any entrepreneur. It is especially difficult with open source projects, since people don't have to work with you.