As an organization or even individual there always seem to be questions when considering whether or not to make your project or code snippet open source. Many times, it starts with trying to figure out which license to use. But there are many other things to consider. We derived a list for you the next time you ask yourself: Should I open source my code?

Any business or even individual who is considering how to open source their code needs to ask of themselves: Who am I and what do I want out of this contribution?

Do you want to:

Build a community of users?

Build a community of contributors?

Seed the market for your business?

Build a business on the code itself?

These are not trivial questions as they directly impact the value that your organization will provide based on the open source decisions you make.

Once you do that, you next need to consider your community.

Open source community

Determine the type of relationship that you as the code/project maintainer would like to have both within and outside of the community. You should ask yourself:



What is my core value?

Am I willing to work with competitors?

Am I wiling to donate my time and energy to the project without any related remuneration?

Is this a services organization that is adding value on top of the code?

Or am I a software developer who will provide additional packages/configuration?

Regardless of who you are, you must embrace the community by:

Finding ancillary projects in the open source community that you can merge with or provide additional value to or that possibly provide obstacles to your objectives. Depending on the scope of your project, this is often the most effective way of expanding your influence. It's often easier to extend than build.

Being prepared to be the primary, if not only, contributor to the code. You know your stuff is good, but do others care?

Being active in the community, publicly. Commitment, commitment, commitment—this is rewarded and will help build your reputation as an upstanding member of a growing community.

Often, I hear from companies who want to open source their code. When asked an encouraging "Why?" a common response is that they want the community to expand their code so the company can benefit. This is an authentic approach, however the amount of effort in building a community is often mis-understood. Don't underestimate how much effort is involved, nor how you might be left holding the ball in the community.

Now that you've determined your relationship with a new or existing community, and presuming that you are, or will be building a company, you'll need to consider your operational model.

Operation and business models

In addition to community activities, you must also determine your business model or mode of operation and how you want to leverage your contributions to the community.

Will you use a subscription model for the community code?

Will you add additional, licensed, proprietary code to what you leverage in the community?

Will you build a service/consulting-only business that takes the open source into customers?

Will you just accept donations?

Other?

Part of this is figuring out how aggressively you will embrace open source. Some companies, such as Red Hat, open source most if not all of their software and focus on building value beyond the bits, whether access to updates, service, support, certification, ecosystem relationships—all of these will determine how far you are willing to embrace the open source community.

Note that if you are a business dependent on revenue from your software and want to open source it—you may have to think differently about your true value as a organization.

As an example, if you are in an industry that values software features heavily, then you're competitors may soon have the exact same features as you! This may very well require that you start to transition your value in the market from being a feature supplier to a feature innovator. If you are the organization that is constantly in front of the community and customers influencing and innovating change, you may find more differentiation from competitors as the leader in the community than a follower.

Legal strategy

Determine your legal strategy by first fully understanding open source and finding a lawyer to help you navigate and choose a license:

How much protection of your brand/trademarks do you need?

Should you brand the community completely separate from your business entity? e.g. Fedora, Wildfly, and RDO (projects); Red Hat Enterprise Linux, JBoss, and Red Hat OpenStack (products).

Are there anciallary benefits that you can engage in to either benefit from or provide benefits to your community and customers? e.g. Promises such as the Open Source Assurance policy from Red Hat provide beneifts beyond the code to customers.

Licenses can dramatically determine your business model, and some licenses will preclude specific activities or limit specific controls you might have over the code once released. Branding in the open source marketplace is also an important consideration.



The open source trump card: Maintain your commitment

Regardless of your motivations, whether making money or building something beyond personal or corporate gain, perhaps the most important aspect of ensuring success with your strategy is your commitment level. Altruistic or not, the success of building a thriving community requires an authentic and honest approach to what you are doing and why. Combining that with an on-going commitment to your stated behavior will help you find a community, your audience, and customers who all recognize and extend the value of your organization and offerings.