Open source code and business models: More than just a license | Opensource.com

Open source code and business models: More than just a license

Posted 15 May 2013 by 

Michael Ferris (Red Hat)
Rating: 
(80 votes)
Open source strategy and business models
Image by : 

opensource.com

submit to reddit

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 renumeration?
  • 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.  

submit to reddit

7 Comments

asrob
Open Minded

A very, very helpful article! Thanks, Michael!

Vote up!
4
Vote down!
0
Andrew Aitken

Excellent article with lots of good content but there are some fundamental questions to start with;
What problem am I trying to solve by open sourcing code?
Why/how do I think open sourcing the code will address this problem?
Do we have the internal fortitude, time and resources it takes to build a community?
And adding to the Community section above;
What scale of community do I need to achieve my goals?
Who are the participants I need to reach and do I have the right technology and value proposition to gain and keep their participation?

Vote up!
4
Vote down!
0
jhibbets
Open Sourcerer

Aren't we at the point now where we should be asking "why should my code be closed source?" first?

Jason

Vote up!
4
Vote down!
0
ncoghlan
Community Member

Unfortunately not - plenty of companies that understand the value the open source model offers to them as a technology consumer still fear the consequences of opening up their own code: "If people can just download the application source code for free, why would they buy it from us?".

This is a particular concern for organisations that use languages that *don't* require a build step to deploy, and/or sell to especially technologically savvy customers (like software development companies).

Encouraging them to turn "we're open source" into a competitive lever through selling points like reduced vendor risk, availability of expertise in the hiring pool, etc, as well as the technical benefits that can arise from opening up development processes (including avoiding the toxic political infighting that can occur in corporate environments), is still a necessary step when trying to persuade current proprietary vendors to avoid the easy path of holding the source code hostage to ensure payment.

Vote up!
0
Vote down!
0
Andrew Aitken

I totally agree, in the case of -new- code, and many organizations are implementing that type of a policy, but there is obviously still vast amounts of proprietary code out there.

Vote up!
2
Vote down!
0
mferris
Open Minded

Andrew - agree with both comments. First "Why", then "How". But back it up with commitment.

Vote up!
0
Vote down!
0
Samar Ali

Thanks a lot Michael for the article, very informative for me and my project.

Vote up!
0
Vote down!
0

Michael Ferris is the Director of Business Architecture at Red Hat and is responsible for consistency of Red Hat's offerings, subscription models, and pricing across all routes to market, programs, and emerging business models. Ferris has more than 20 years of experience in enterprise software development and management. He led product marketing and management teams at Red Hat during the conception, definition, and was responsible for the first three releases of the Red Hat Enterprise Linux

Reader favorite