What do you want?

When planning for an open source release, the threshold question is about what you want to accomplish. If your goal is just to get something out in the open, "throw it over the wall" as the saying goes, then relatively little preparation is needed. Preparing and releasing the code accomplishes your goal. But don't expect to just throw something out and automatically receive widespread feedback and engagement.

Most companies want something else - positive recognition, engagement, feedback, and interest from others. For some companies, it may also be a goal to have others participate in the future development of the project. In short, most companies want to develop a community.

Assuming that your goal is to develop a community, you need an internal return-on-investment strategy and a market-entering strategy. With those in place you can develop specific tactics that will help you achieve your goals.

The internal return-on-investment strategy is about how your organization will maintain the necessary energy and investment needed over the long run. Broadly speaking, it is about the business model your company will use to create and sustain revenue while working on the project. Without a clearly-defined ROI, many companies end up backing off during the trough that usually precedes broader success.

The market-entering strategy is about how your project will be positioned to enter and grow its user and contribution base in a self-sustaining cycle. And yes, I said market. Your open source project is a product of your company. It just happens that the monetary price for the source code of your product is $0. That doesn't mean that people will immediately flock to your project. There are other costs - time, effort, and opportunity costs - that are borne by anyone wanting to adopt or contribute to your project. Your market-entering strategy is about convincing people that your project has value that exceeds those costs.

The tactics are partially dictated by the ROI strategy and the market-entering strategy. Accordingly, some of these tactics will be specific to your company and your project. But many common tactics are dictated by the open source arena itself.

As noted above, we have discussed internal ROI strategies in previous articles. The remainder of this article will focus on how to develop your market-entering strategy.

Defining a new market - what is needed?

For an open source project to be successful, it usually needs three things: 1) a new capability; 2) a clear path to contribute; and 3) the promise of future improvement.

A new capability

An open source project should have something novel that sets it apart, making the project more suited to a particular user or a particular use case. This is especially important for new projects. This new capability may be a unique feature, better performance, or the addressing of a specific issue that hasn't been tackled before. The novelty acts as a competitive advantage. It positions the project in a unique space in the market and provides a reason why developers should engage with your project instead of using existing solutions. It may be helpful to think about it in terms of what differentiated value you expect your project to provide.

It is much better when the novel feature addresses a need that you or your company have that is not well served by existing projects or products. Not only will the project "scratch your own itch," helping with the internal ROI, but your own needs are probably similar to others. Solving the problem for yourself will likely solve the same problem for others. This creates a built-in audience of interested people.

A clear path to contribute

There two ways in which a project needs a clear path to contribute. First, your project needs flaws or missing features. It may sound strange that a project should have flaws, but "perfect" projects have no community! The flaws can't be showstoppers. Your project must provide the new functionality advertised. But when people see that a project is so close to addressing their needs they will be motivated to add that little bit of effort to make the project advance.

The second aspect of a clear path to contribution revolves around lowering the technical and social barriers to contribution. Your project should be easy to install, with accessible code. There should be a public issue tracker. It means having good documentation, straightforward onboarding processes, and responsive maintainers. People will expend some effort if they perceive that it will make a difference. But if getting involved is too hard, people will give up before anyone knows that they might have been a contributor.

The promise of future improvement

Projects should have a roadmap or vision for future development. The roadmap should be ambitious but achievable, giving contributors a sense of direction and end-users comfort that the project will be around for the long term. Communicating clearly about goals and progress builds trust and credibility. People want assurance that their investment of time and effort will have enduring value.

If your company is thinking about releasing a project as open source, think about these three things. Make sure you can express what the new capability is, what is still missing, and the plan to get better. If all three of these things are present, then you have the basic ingredients for a successful community.